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Abstract 

^  One  of  the  characteristics  of  real-time  systems  is  concurrency.  Designers  of  real¬ 
time  systems  have  traditionally  determined  system  concurrency  at  implementation 
time  using  the  facilities  of  a  cyclic  executive.  With  the  advent  of  programming 
language  constructs  for  specifying  concurrency,  determining  concurrency  at  design 
time  hus  become  a  possibility. 


Several  design  methods,  all  of  which  are  extensions  of  either  Structured  Design 
or  Jackson  System  Development,  provide  heuristics  to  help  the  designer  make  con¬ 
currency  decisions.  The  object-oriented  approach,  however,  has  no  corresponding 
heuristics  to  aid  designers  of  real-time  sy terns. 

The  purpose  of  this  thesis  Wcis  to  develop  heuristics  to  help  designers  make 
concurrency  decisions  in  developing  object-oriented  designs  of  real-time  systems. 
This  was  accomplished  by  examining  existing  heuristics  from  other  design  methods 
and  applying  them  to  the  object-oriented  paradigm. 

Four  heuristics  were  developed,  the  first  of  which  exploits  the  potential  in 
object-oriented  design  to  model  the  problem-space.  The  other  three  heuristics  deal 
with  concurrency  which  is  not  necessarily  reflected  in  the  problem-space,  but  must 
be  implemented  for  practical  reasons. 


The  heuristics  were  validated  by  applying  them  to  a  sample  problem,  then 
having  the  heuristics  and  the  design  of  the  sample  problem  evaluated  by  a  group  of 
software  engineering  experts.  ^ 
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DETERMINING  CONCURRENCY  IN  OBJECT-ORIENTED 

DESIGN 

OF  REAL-TIME  EMBEDDED  SYSTEMS 
USING  ADA 


L  Introduction 

The  design  of  embedded,  real-time  systems  is  considered  one  of  the  most  com¬ 
plex  software  related  activities[Levi  and  Agrawala  1987:3].  Journal  articles  and  text¬ 
books  dealing  with  real-time  software  design  have  increased  in  number  and  frequency 
as  researchers  attempt  to  reduce  complexity  and  help  designers  in  their  task.  This 
thesis  discusses  the  application  of  object-oriented  design  techniques  to  real-time  sys¬ 
tems. 

1.1  Background 

An  embedded  computer  systems  is  one  in  which  the  computer  is  a  critical  part 
of  a  larger  system [S canned ,  et  al.  1986:3].  These  systems  are  usually  large,  complex, 
and  subject  to  strict  reliability  and  timing  requirements[Booch  1987b:  15]. 

A  real-time  software  system  is  one  which  must  respond  ..o  events  or  conditions 
in  the  external  environment  within  a  specified  time  periodflEEE  1983].  As  this 
aspect  of  embedded  systems  leads  directly  to  a  consideration  of  concurrency  in  the 
system,  this  thesis  focuses  on  real-time  software  design. 

One  of  the  primary  characteristics  of  real-time  systems  is  concurrency[Gomaa 
1989b],  which  occurs  when  the  execution  of  two  or  more  processes  is  overlapped  in 
time,  f.e.,  at  least  one  process  begins  execution  prior  to  the  termination  of  some 
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other  process.  These  processes  may  be  distributed  on  multiple  processors  or  share  a 
single  processor. 

Traditionally,  concurrency  in  real-time  systems  has  been  handled  via  a  cyclic 
executive,  which  is  essentially  a  real-time  extension  to  the  operating  system,  provid¬ 
ing  facilities  for  creation,  execution,  and  termination  of  concurrent  processes[Sha  and 
Goodenough:!].  Under  a  cyclic  executive,  each  process  is  allotted  a  certain  amount 
of  execution  time,  at  the  end  of  which  the  process  is  suspended  and  another  process 
scheduled.  Handling  concurrency  then  becomes  strictly  an  implementation  issue, 
since  software  modules  that  cannot  execute  within  their  time  frame  must  then  be 
decomposed  into  smaller  components,  not  on  the  basis  of  design  considerations,  but 
on  the  basis  of  execution  time. 

The  Ada  programming  language,  introduced  in  the  1980’s,  provides  language 
constructs  for  specifying  concurrent  processes  without  forcing  the  programmer  to 
explicitly  use  a  real-time  executive.  This  enables  the  designer  to  nfiake  concurrency 
decisions  at  design  time  based  on  sound  design  principles,  rather  than  at  implemen¬ 
tation  time  based  on  timing  considerations. 

The  designer  of  real-time  systems,  therefore,  must  identify  which  processes  in 
the  software  design  are  concurrent  and  which  are  not.  Until  recently,  there  has  been 
little  guidance  for  identifying  concurrency,  but  several  researchers  have  developed 
heuristics  for  determining  when  a  process  should  be  implemented  as  a  concurrent 
process[Gomaa  1984,  Nielsen  and  Shumate  1988,  Sanden  1989].  These  heuristics  are 
presented  in  the  context  of  Structured  Design[Ward  and  Mellor  1985]  or  Jackson 
System  Development  [Jackson  1983].  One  method  that  does  not  have  comparable 
heuristics  is  object-oriented  design[Kelly  1987:245]. 

Object-oriented  design  m.odels  the  software  as  objects  corresponding  to  entities 
in  the  real  world[Booch  1987b:47].  Associated  with  each  object  is  a  set  of  operations 
which  acts  on  the  object.  The  software  system  is  implemented  by  specifying  the 
interaction  of  the  objects  via  their  operations. 
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The  object-oriented  method  followed  in  this  thesis  is  that  described  by  Booch[Booch 
1991],  which  is  an  iterative  process  of  identifying  objects  and  operations,  determining 
the  visibility  and  interfaces  between  objects,  and  then  implementing  the  objects.  As 
new  objects  are  encountered  during  the  design,  the  process  is  repeated.  This  con¬ 
tinues  until  all  objects  are  implemented.  Chapter  three  contains  a  fuller  discussion 
of  object-oriented  design  and  Booch’s  method. 

l.S  Problem 

At  present,  designers  of  object-oriented  real-time  systems  have  little  guidance 
in  determining  concurrency  in  their  designs[Kelly  1987).  The  objective  of  this  thesis 
is  to  develop  heuristics  for  identifying  concurrency  in  an  object-oriented,  real-time 
design. 

Specifically,  the  objectives  are  as  follows: 

•  Determine  what  heuristics  exist  for  determining  concurrency  using  other  design 
methods. 

•  Define  heuristics  for  determining  concurrency  using  object-oriented  design. 

•  Validate  the  heuristics  by  applying  them  to  a  sample  problem  and  then  having 
a  panel  of  experts  pass  judgement  on  the  validity  of  the  heuristics. 

1.3  Scope 

This  thesis  concentrates  on  real-time  systems  implemented  on  single-processors. 
Concurrency  in  distributed,  multi-processor  systems  depends  on  factors  external  to 
the  design,  such  as  the  processor  interconnection  network,  the  communication  mech¬ 
anism,  and  the  number  of  processors  available.  Assuming  a  single-processor  environ¬ 
ment  allows  the  designer  to  focus  on  the  design  itself,  independent  of  implementation 
platform.  Even  in  a  distributed  environment  there  may  be  several  processes  execut¬ 
ing  on  the  same  processor,  so  the  single-processor  heuristics  apply  in  any  case. 
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1.4  Assumptions 

The  design  principles  developed  in  this  thesis  are  independent  of  implemen¬ 
tation  language.  However,  the  language  used  to  verify  the  principles  is  Ada.  Ac¬ 
cordingly,  the  benefits  and  constraints  of  the  Ada  tasking  model  have  affected  the 
resulting  design. 

1.5  Approach 

The  research  to  achieve  the  goals  of  this  thesis  was  accomplished  in  the  follow¬ 
ing  stages: 

1.  Literature  Survey.  Over  the  past  25  years  a  vast  amount  of  research  concerning 
software  system  design  has  been  done.  A  survey  of  this  research  was  conducted, 
focusing  on  current  developments  in  the  design  of  real-time  systems,  and  in  de¬ 
termining  concurrency  in  these  designs.  Specifically,  three  design  paradigms 
were  investigated:  real-time  extensions  to  Structured  Analysis/Structured  De¬ 
sign  (SA/SD)[Ward  and  Mellor  1985],  Jackson  System  Development  [Jackson 
1983],  and  object-oriented  design[Booch  1991].  The  results  of  this  survey  are 
in  chapter  two  of  this  thesis. 

2.  Develop  Design  Heuristics.  Based  on  the  principles  and  heuristics  examined  in 
the  literature  survey,  a  set  of  heuristics  specifically  addressing  concurrency  in 
object-oriented  real-time  systems  were  developed.  The  heuristics  are  described 
in  chapter  three. 

3.  Validation  of  Heuristics.  The  validation  of  the  concurrency  heuristics  took 
place  in  two  stages.  First,  the  heuristics  were  applied  to  a  sample  problem.  An 
air  traffic  control  simulation  (ATC)  was  selected  because  it  exhibited  sufficient 
concurrency  to  demonstrate  the  heuristics,  while  being  small  enough  to  manage 
in  an  academic  environment.  The  discussion  of  the  ATC  design  is  in  chapter 
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four,  and  the  object-oriented  requirements  analysis  and  the  Ada  specifications 
for  the  architectural  design  can  be  found  ;in  appendix  A. 

For  the  second  stage  of  validation,  the  heuristics  were  distributed  to 
several  experts  in  software  engineering  whose  opinions  on  various  aspects  of 
the  heuristics  were  tabulated.  Chapter  five  contains  a  detailed  discussion  of 
this  effort  and  appendix  B  contains  the  validation  package, 

1.6  Thesis  Organization 

The  thesis  is  organized  to  follow  the  stages  of  research  outlined  in  the  Approach 
section.  Chapter  two  presents  a  review  of  current  literature  concerning  concurrency 
in  the  design  of  real-time  software  systems.  Chapter  three  outlines  a  set  of  heuristics 
which  designers  can  apply  to  object-oriented  design  of  real-time  systems  to  detennine 
concurrency  in  the  system.  Chapter  four  contains  the  results  of  applying  these 
heuristics  to  a  sample  problem,  an  Air  'I'raffic  Control  (ATC)  simulation.  Chapter 
five  records  the  validation  method  and  results  for  the  heuristics.  The  thesis  concludes 
with  a  chapter  in  which  conclusions  are  drawn  and  recommendations  for  further  work 
are  given. 
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IL  Literature  Survey 


2.1  Introduction 

Real-time  systems  normally  exhibit  a  high  degree  of  concurrency  [Gomaa  1989b]. 
Consequently,  a  real-time  design  method  should  provide  guidance  for  designers  to 
help  identify  and  implement  concurrency.  This  survey  examines  how  current  real¬ 
time  design  methods  assist  designers  in  making  concurrency  decisions.  Five  exten¬ 
sions  to  Yourdon’s  Structured  Analysis  are  considered  first:  Structured  Development 
for  Real-time  Systems,  Design  Approach  for  Real-time  Systems  (DARTS),  Layered 
Virtual  Machine/Object-Oriented  Design  (LVM/OOD),  Ada-based  Design  Approach 
for  Real-time  systems  (AD ARTS),  and  Process  Abstraction  Method  for  Embedded 
Large  Applications  (PAMELA).  Jackson  System  Development  (JSD)  is  then  exam¬ 
ined,  along  with  a  related  method,  Entity-Life  Modeling.  The  chapter  concludes 
with  a  brief  discussion  of  Object-Oriented  Design. 

2.2  Structured  Development  for  Real-time  Systems 

Structured  Design [Yourdon  and  Constantine  1979],  a  method  of  classical  de¬ 
sign  in  which  the  system  under  consideration  is  structured  into  transforms  and  data 
flows,  has  been  popular  with  business  data  processing  systems  for  a  number  of  years. 
The  design  approach,  though,  addresses  data  manipulation  mainly,  and  only  periph¬ 
erally  touches  on  control  and  concurrency  features  characteristic  of  real-time  and 
embedded  systems[Ward  and  Mellor  1985].  Ward  and  Mellor  introduced  “. . .  control 
considerations,  through  the  use  of  state  transition  diagrams.  A  control  transforma¬ 
tion  represents  the  execution  of  a  state  transition  diagram”  [Gomaa  1989b:9].  Thus,  a 
state  transition  diagram  may  be  associated  with  each  control  transform  to  represent 
the  dynamic  behavior  of  the  systemfWard  1986:201]. 

The  control  and  data  transformations  are  graphically  represented  by  a  Data 
Flow  Diagram  (DFD).  After  the  DFD  is  developed,  the  transforms  are  allocated  to 
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processors  and  the  transforms  on  each  processor  are  allocated  to  concurrent  tasks. 
Structured  Design  is  then  iteratively  applied  to  design  the  tasks[Gomaa  1989b:10]. 
Structured  Design  provides  a  method  by  which  individual  tasks  can  be  designed,  but 
little  help  is  given  in  structuring  the  system  into  concurrent  tasks.  Gomaa  notes  that 
“. . .  Structured  Design  is  a  program  design  method  leading  primarily  to  functional 
modules  and  does  not  address  the  issues  of  structuring  a  system  into  concurrent 
tasks”  [Gomaa  1989b:ll]. 

2.3  Design  Approach  for  Real-time  Systems  (DARTS) 

The  DARTS  method  provides  an  approach  for  structuring  a  real-time  sys¬ 
tem  into  concurrent  tasks[Gomaa  1984].  Using  a  DFD,  which  is  developed  using 
Structured  Design  techniques,  concurrency  is  identified  by  considering  the  nature 
of  the  transforms  and  grouping  them  according  to  the  following  task  structuring 
criteria[Gomaa  1984:940). 

•  Dependency  on  Input/Output.  A  transform  associated  with  an  I/O  device 
should  be  a  separate  task. 

•  Time-critical  Functions.  A  transform  which  executes  under  tight  time  con¬ 
straints  needs  to  run  at  a  high  priority  and  should  be  a  separate  task. 

•  Computational  Requirements.  A  transform  which  requires  extensive  calcula¬ 
tion  needs  to  run  at  a  low  priority  (perhaps  in  background)  and  should  be  a 
separate  task. 

•  Functional  Cohesion.  Two  or  more  transforms  that  perform  similar  functions 
can  be  grouped  into  a  single  task. 

•  Temporal  Cohesion.  Two  or  more  transforms  that  perform  functions  during 
the  same  time  period  can  be  grouped  into  a  single  task. 

•  Periodic  Execution.  Transforms  that  execute  at  regular  intervals  can  be  grouped 
into  a  single  task. 
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Once  the  tasks  are  identified,  the  task  interfaces  are  designed  and  the  tasks 
are  themselves  designed,  again  using  Structured  Design  techniques. 

2.4  Layered  Virtual  Maclime/Objcct-Oriented  Design  (LVM/OOD) 

LVM/OOD  is  a  data-flow  based  design  method  developed  by  Nielsen  and  Shu- 
mate[Nielsen  and  Shumate  1988]. 


“The  concept  of  LVM  is  used  to  create  a  top  layer  as  a  set  of  communicat¬ 
ing  sequential  processes.  Each  process  is  a  virtual  machine  that  executes 
in  parallel  with  the  other  processes  (virtual  machines).  We  combine 
the  concepts  of  LVM  and  OOD  (LVM/OOD)  to  decompose  each  pro¬ 
cess  into  a  hierarchy  of  virtual  machines  (Ada  subprograms)  and  objects 
(Ada  packages,  types,  and  operations  on  objects  of  the  type)”  [Nielsen 
and  Shumate:33]. 


The  method  consists  of  ten  steps[Nielsen  and  Shumate:211f].  The  first  three 
steps  are  concerned  with  producing  a  Structured  Design,  t.e.,  the  data  flow  diagram, 
data  dictionary,  etc.  InThe  fourth  step,  the  step  in  which  concurrency  is  determined, 
process  selection  rules  are  applied  to  the  DFD  to  combine  transforms  into  concur¬ 
rent  processes[Nielsen  and  Shumate:212|.  The  first  six  process  selection  rules  are 
identical  to  Gomaa’s  task  structuring  criteria(Comaa  1984:940],  listed  above[Nielsen 
and  Shumate:90-91].  Two  rules  have  been  added: 


•  Storage  Limitations.  If  processes  are  too  large,  they  will  need  to  be  split  into 
smaller  processes. 

•  Data  Base  Functions.  Transforms  needing  access  to  shared  data  can  be  grouped 
in  a  single  process  to  provide  for  mutual  exclusion[Nielsen  and  Shumate:90-91]. 
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2.5  Ada-based  Design  Approach  for  Real-time  Systems  (ADARTS) 

In  a  recent  article,  Gomaa  modified  the  original  DARTS  method  to  specifi¬ 
cally  address  designing  real-time  systems  using  Ada,  which  he  calls  ADARTS[Gomaa 
1989a]. 

In  ADARTS,  the  task  structuring  criteria  are  expanded  and  reorganized  as 
follows: 

1.  Event  Dependency  Criteria.  These  criteria  are  concerned  with  how  and  when 

a  task  is  activated.  Included  in  this  category  are  the  following: 

(a)  Asynchronous  Device  I/O  Dependency.  This  is  the  same  as  the  D.ARTS 
Dependency  on  I/O. 

(b)  Periodic  Event.  This  is  the  same  as  the  DARTS  Periodic  Execution. 

(c)  Periodic  I/O.  The  task  activation  is  periodic,  but  is  related  to  some  I/O 
device. 

(d)  Contr  .  Function.  This  is  a  function  which  may  be  represented  by  a  state 
transition  diagram. 

(e)  Entity  Modeling.  This  is  a  task  which  models  concurrency  in  the  problem 
environment. 

(f)  User  Interface  Dependency.  Sequential  operations  performed  by  the  user 
can  be  grouped  into  a  single  task. 

2.  Task  Cohesion  Criteria.  These  criteria  provide  a  basis  for  determining  which 

functions  can  be  combined  into  tasks. 

(a)  Sequential  Cohesion.  Fucnctions  that  must  be  carried  out  .sequentially 
can  be  grouped  into  a  single  task. 

(b)  Temporal  Cohesion.  This  is  the  same  as  the  DARTS  Temporal  Cohesion. 
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(c)  Functional  Cohesion.  This  is  the  same  as  the  DARTS  Functional  Cohe¬ 
sion. 

3.  Task  Priority  Criteria.  The  criteria  are  based  on  the  priorities  of  the  functions. 

(a)  Time  Critical.  This  is  the  same  as  the  DARTS  Time  Critical  Functions. 

(b)  Computationally  Intensive.  This  is  the  same  as  the  DARTS  Computa¬ 
tional  Requirements. 

2.6  Frocess  Abstraction  Method  for  Embedded  Large  Applications  (PAMELA) 

PAMELA  is  an  Ada-based  design  method  developed  by  George  Cherry[Cherry 

1986] .  Since  most  information  on  PAMELA  is  proprietary,  the  material  in  this 
section  is  taken  from  two  articles  comparing  PAMELA  with  other  methods[Kelly 

1987] [Boyd  1987]. 

PAMELA  is  a  process-oriented  method,  i.e.,  the  dynamic  properties  of  the 
system  under  consideration  are  given  priority  over  the  static  structure.  These  two 
views  of  the  system  are  represented  by  process  modules  and  procedure  modules, 
respectively.  Processes  have  “. . .  one  or  more  independent  threads  of  control(run  time 
stack)... ’’[Boyd  1987:4-69]  and  conserve  local  state.  Procedure  modules  “...have 
no  independent  thread  of  control,  and  cannot  conserve  local  state  information”  [Boyd 
1987:4-69]. 

PAMELA  is  actually  an  extension  of  Structured  Design.  The  top  level  of  ab¬ 
straction  in  a  PAMELA  design  “. . .  is  essentially  a  data  flow  diagram  of  processes 
. . .’’[Kelly  1987:241].  Boyd  states,  “In  effect,  PAMELA  supports  a  functional  (pro¬ 
cedural)  decomposition  . .  .’’[Boyd  1987:4-69]. 

The  heuristic  PAMELA  provides  for  determining  these  independent  threads  of 
control  is  to  identify  asynchronous  processing  in  the  system.  According  to  Boyd[Boyd 
1987:4-69], 
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A  guiding  principle ’S  to  isolaie  fas  much  as  possible)  those  interactions 
•vhich  reouire  asynchronous  lianciling  in  the  highest  regions  of  a  system 
design;  this  leads  to  processes  at  the  higher  levels  of  the  system.  Sequen¬ 
tial  processing  of  information  takes  place  at  lower  levels  of  the  hierarchy, 
effectively  isolated  within  the  decomposition  of  asynchronous  processes. 


2.1  Jackson  Syste^n  Developmeni(JSD) 

Jackson  System  Development  (JSD)  incorporates  a  design  method  in  which  the 
real  world  is  modeled  “in  terms  of  entities,  actions  they  perform  or  suffer,  and  the 
orderings  of  those  actions.” [Jackson  1983:23]  Thus  the  focus  is  not  on  a  step-by-step 
progression  of  functions  acting  upon  data. 

A  complete  description  of  JSD  can  be  found  in  [Jackson  1983].  The  following 
discussion  is  drawn  from  [Cameron  1986]  as  it  provides  a  concise  overview  of  the 
method  and  discusses  the  relevant  concurrency  issues. 

A  JSD  specification  consists  of  a  network  of  sequential  processes  communi¬ 
cating  via  message  passing  and  access  to  the  process’s  local,  read-only  data.  This 
specification  is  produced  by  completing  three  phases: 


1.  Modeling  phase[Cameron  1986:222],  This  phase  is  concerned  primarily  with 
identifying  the  events  or  actions  occurring  in  that  portion  of  the  real  world 
which  is  to  be  modeled.  Each  action  will  be  associated  with  one  or  more 
entities  or  objects.  These  action-entity  associations  are  then  grouped  and 
ordered,  producing  a  set  of  sequential  processes.  Each  of  these  processes  is 
then  referred  to  as  a  process  model. 


2.  Network  phase[Cameron  1986:228].  The  network  phase  determines  the  inter¬ 
connections  of  the  process  models.  Processes  can  communicate  by  two  means, 
data  streams  and  state  vectors.  A  data  stream  is  basically  a  first  in,  first-out 
(FIFO)  message  queue.  The  state  vector  consists  of  a  process’s  local  data 
which  is  available  for  inspection  by  other  processes  on  a  read-only  basis. 
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3.  Implementation  phase[Cameron  1986:2331].  In  this  phase  each  of  tlie  process 
models  is  implemented  in  some  programming  language.  This  is  the  step  in 
which  concurrency  decisions  are  made.  Theoretically,  every  process  model  can 
be  implemented  as  a  concurrent  process.  This  may  not  be  desirable,  especially 
in  a  single-processor  system,  as  significant  inefficiency  may  result.  One  way 
to  alleviate  this  is  to  convert  the  processes  to  subroutines  and  combine  the 
whole  program  into  one  process.  Of  course,  these  are  the  two  extremes;  the 
designer  decides  which  processes  are  actually  implemented  concurrently  and 
which  are  converted  into  subroutines.  How  the  designer  makes  these  decisions 
is  not  addressed. 

8.8  Entity-Life  Modeling 

Entity-life  Modeling  is  a  JSD-based  method  developed  by  Sanden[Sanden  1989). 
While  JSD  identifies  many  concurrent  processes  when  applied  to  real-time  problems, 
the  goal  of  Entity-life  Modeling  (also  called  Object-life  Modeling(Sanden  1989])  is  to 
implement  in  software  only  those  concurrent  processes  which  model  concurrency  in 
the  problem  environment.  “The  aim  is  to  pattern  the  software  structure  on  struc¬ 
tures  found  in  the  problem  nvironment  and  minimizing  the  amount  of  extra  material 
introduced  for  the  administration  of  the  software  itself” [Sanden  1990:16]. 

The  designer  accomplishes  this  by  identifying  complex  behavior  patterns  in 
the  problem  environment.  “When  using  the  approach,  the  analyst/designer  starts 
by  looking  for  complex,  yet  purely  sequential,  behavior  patterns  in  the  problem  envi¬ 
ronment.  The  objective  is  to  capture  as  much  of  the  problem  complexity  as  possible 
in  as  few  behavior  patterns  as  possible,  and,  generally,  the  more  complexity  that  can 
be  captured  in  a  single  sequential  behavior  pattern,  the  better” [Sanden  1989:1459]. 
This  complex  behavior  is  defined  as  “the  timing  aiid  doling  uf  opeialions  on  various 
objects”  [Sanden  1990:17]. 

Each  of  these  behavior  patterns  is  implemented  as  a  concurrent  task.  Ideall}^, 
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this  is  the  minimum  necessary  concurrency,  but  practical  considerations  may  require 
additional  concurrency  in  the  solution.  For  example,  a  task  may  be  introduced  to 
provide  for  mutual  exclusion  in  a  shared  data  storefSanden  1990:298]. 

2.9  Object-Oriented  Design 

According  to  Booch,  “Object-oriented  design  is  a  method  of  design  encom¬ 
passing  the  process  of  object-oriented  decomposition  and  a  notation  for  depicting 
both  logical  and  physical  as  well  as  static  and  dynamic  models  of  the  system  under 
design” [Booch  1991:37].  In  object-oriented  decomposition,  the  problem  environment 
is  viewed  as  a  set  of  objects  and  the  operations  suffered  by  thos''  objects.  Design 
consists  of  identifying  the  objects  and  operations  and  specifying  the  interaction  of 
the  objects. 

Concurrency  in  Object-Oriented  Design  is  determined  when  the  operations  are 
identified,  as  this  is  when  the  dynamic  behavior  of  the  object  is  specified[Booch 
1987b:337].  An  object  which  exhibits  significant  dynamic  behavior  is  said  to  repre¬ 
sent  an  independent  thread  of  control,  and  is  called  active[Booch  1991:66].  Thus,  the 
world  can  be  viewed  “...  as  consisting  of  a  set  of  cc  perative  objects,  some  of  which 
are  active  and  thus  serve  as  centers  of  independent  activity”  [Booch  1991:66].  Chap¬ 
ter  three  of  this  thesis  expands  further  on  Object-Oriented  Design  and  concurrency- 
related  issues. 

2.10  Conclusion 

The  Object-Oriented  Design  paradigm  provides  general  guidance  for  determin¬ 
ing  which  objects  are  concurrent,  i.e.,  identifying  active  objects.  The  designer  does 
not  have  specific  criteria  to  aid  in  this  determination,  nor  is  the  possibility  of  multiple 
concurrent  operations  on  the  same  object  addressed. 

On  the  other  hand,  a  designer  applying  Structured  Design  has  specific  criteria 
to  apply  to  a  DFD  to  determine  concurrency,  through  DARTS,  LVM/OOD,  and 
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ADARTS.  Entity-life  Modeling  also  provides  heuristics  for  identifying  concurrency. 
Kelly  claims  that  PAMELA’S  support  of  concurrency  is  very  stroiig[Kelly  1987:245]. 

Chapter  Three  of  this  thesis  provides  heuristics  which  can  be  applied  to  an 
object-oriented  design  to  determine  concurrency.  The  heuristics  are  based  on  the 
work  of  Gomaa  (DARTS,  ADARTS),  Nielsen  and  Shumate  (LVM/OOD),  and  Sanden 
(Entity-life  Modeling). 


III.  Heuristics  for  Determining  Concurrency  in  Object-Oriented 

Design 

This  chapter  details  the  heuristics  a  designer  may  use  to  determine  concurrency 
in  an  object-oriented  design.  A  discussion  of  object-oriented  design  is  presented 
first,  followed  by  a  description  of  Booch’s  Object-Oriented  Design  method.  The 
concurrency  heuristics,  which  are  based  on  the  work  surveyed  in  chapter  two,  are 
then  given. 

3.1  Object-Oriented  Design 

Object-oriented  design  is  a  design  approach  in  which  the  problem  environment 
is  modeled  as  a  collection  of  interacting  objects  and  classes.  The  object  interactions 
are  referred  to  as  messages  or  operations[Booch  1991:80]. 

The  object-oriented  paradigm  is  based  on  the  concepts  of  abstraction  and  in¬ 
formation  hiding[Booch  1991:38).  Pressman  states 


The  unique  nature  of  object-oriented  design  lies  in  its  ability  to  build 
upon  three  important  software  design  concepts:  abstraction,  information 
hiding,  and  modularity.  All  design  methods  strive  for  software  that  ex¬ 
hibits  these  fundamental  characteristics,  but  only  OOD  provides  a  mech¬ 
anism  that  enables  the  designer  to  achieve  all  three  without  complexity 
or  compromise[Pressman  1987:334). 


Application  of  these  concepts  produces  a  hierarchical  object  structure,  where 
hierarchy  is  defined  as  “...a  ranking  or  ordering  of  abstractions” [Booch  1991:54). 
Booch  defines  tv.’o  sets  of  hierarchies,  the  “kind  of” /“part  of”  hierarchies,  and  the 
using/containing  hierarchies[Booch  1991:54,88).  The  “kind  of”/“part  of”  hierarchies 
deal  with  objects  which  are  instantiations  of  a  class  of  objects  and  objects  which  are 
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component  parts  of  another  object.  These  concepts  apply  directly  to  object-oriented 
programming  languages  and  techniques,  but  are  not  crucial  at  design  time. 

Using/containing  hierarchies,  however,  are  important  for  object-oriented  de¬ 
sign.  The  using  hierarchy  demonstrates  the  relationships  among  objects  which  re¬ 
quire  services  of  other  objects  and  objects  which  provide  services  to  other  objects. 
Booch  calls  the  former  “actor”  objects  and  the  latter  “server”  objects;  objects  which 
both  require  and  provide  services  are  called  “agents” [Booch  1991:89). 

The  containing  hierarchy  demonstrates  the  relationships  between  objects  which 
“enclose”  other  objects  and  the  objects  “within”  the  enclosing  objects.  In  other 
words,  some  objects  are  completely  hidden  within  another  object. 

Seidewitz  calls  the  using  and  containing  hierarchies  the  seniority  and  composi¬ 
tion  hierarchy,  respectively.  He  states  that  the  “. . .  composition  hierarchy  deals  with 
the  composition  of  larger  objects  from  smaller  component  objects.  The  seniority 
hierarchy  deals  with  the  organization  of  a  set  of  objects  into  “layers”.  Each  layer 
defines  a  virtual  machine  that  provides  services  to  senior  layers”  [Seidewitz  1989:97). 

Consider,  for  example,  the  air  traffic  control  simulation  whose  design  is  pre¬ 
sented  in  chapter  four.  An  example  of  the  composition  hierarchy  would  be  the 
Console  object  and  its  related  sub-objects.  Display  and  Keyboard.  Console  con¬ 
tains  those  two  objects  (Figure  3.1).  The  ATC  object  however,  does  not  contain 
the  Console  object,  i.e.,  it  is  not  composed  of  Console;  ATC  does,  however,  use  the 
services  provided  by  the  Console  object  (Figure  3.2).  Note  that  although  the  ATC 
and  Console  objects  are  at  the  same  level  of  abstraction,  the  ATC  is  a  higher  level 
virtual  machine  layer  than  Console,  since  ATC  requires  operations  of  Console,  but 
Console  requires  no  operations  of  ATC. 

When  an  object  is  just  one  of  several  instantiations  of  the  same  type  of  object, 
the  object  type  is  referred  to  as  a  class  of  objects,  which  is  ”...  a  set  of  objects  that 
share  a  common  structure  and  a  common  behavior” [Booch  1991:93). 
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CONSOLE 


In  object-oriented  programming  languages,  such  as  Smalltalk  and  the 

class  concept  is  related  to  the  concept  of  inheritance.  Inheritance  is  a  relationship 
among  objects  where  one  object  or  class  shares  the  structure  of  one  or  more  objects 

or  classes,  i.e.,  an  object  or  class  “inherits”  the  structure  or  behavior  of  another 

* 

object  or  class.  Ada  does  not  directly  support  inheritance,  so  the  class  concept  is 
not  as  important  as  in  other  languages.  Consequently,  this  thesis  does  not  consider 
inheritance  in  the  design  of  systems. 

The  class  concept  is  still  useful  in  determining  concurrency  since  a  single  con¬ 
current  object  produces  a  different  design  and  implementation  from  a  concurrent 
class,  which  may  have  multiple  concurrent  instantiations.  Also,  identifying  classes 
of  objects  is  important  from  a  reusability  standpoint.  If  an  object  is  a  member  of  a 
previously  implemented  class,  then  that  object  need  not  be  reimplemented. 

3.2  Booch’s  Method 

The  object-oriented  design  method  used  in  this  thesis  is  Booch’s  Object-Oriented 
Design  as  presented  in  [Booch  1991:187-196).  The  steps  of  the  method  are: 

•  Identify  the  classes  and  objects  at  a  given  level  of  abstraction. 
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•  Identify  the  semantics  of  the  classes  and  objects. 

•  Identify  the  relationships  among  the  classes  and  objects. 

•  Implement  the  classes  and  objects. 

The  application  of  this  method  is  not  just  a  matter  of  mechanically  performing 
the  steps  in  sequence.  Booch  notes:  “this  is  an  incremental  process:  the  identification 
of  new  classes  and  objects  usually  causes  us  to  refine  and  improve  upon  the  semantics 
of  and  relationships  among  existing  classes  and  objects.  It  is  also  an  iterative  process: 
implementing  classes  and  objects  often  leads  us  to  the  discovery  or  invention  of  new 
classes  and  objects  whose  presence  simplifies  and  generalizes  our  designs”  [Booch 
1991:190]. 

Normally,  software  design  is  preceded  by  an  analysis  step  in  which  the  problem 
statement  is  analyzed  and  a  requirements  specification  is  produced[Fairley  1985:38]. 
Booch’s  method  does  not  preclude  this  approach;  object-oriented  analysis  is  consid¬ 
ered  an  “...  ideal  front  end  to  object-oriented  design” [Booch  1991:141].  However, 
when  applying  object-oriented  analysis,  the  distinction  between  analysis  and  de- 
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sign  is  somewhat  artificial  and  difficult  to  maintain [Sanden  1990:32].  Therefore,  no 
attempt  is  made  in  this  thesis  to  separate  the  two. 

The  analysis/design  in  this  thesis  will  be  accomplished  using  an  Object-Class 
Specification,  which  is  a  combination  of  graphical  and  textual  representation  of  and 
object  or  class.  It  shows  an  object’s  or  claiss’s  components,  operations,  static  and  dy¬ 
namic  relationships,  and  other  information  pertinent  to  design  and  implementation. 
An  example  can  be  found  in  Figure  3.3. 


S.2.1  Identify  the  classes  and  objects  at  a  given  level  of  abstraction.  This  step 
consists  of  “. . .  two  activities:  the  discovery  of  the  key  abstractions  in  the  problem 
space  (the  significant  classes  and  objects)  and  the  invention  of  the  important  mech- 
tr’sms  that  provide  the  behavior  required  of  objects  that  work  together  to  achieve 
Svine  function” [Booch  1991:191].  Generally,  the  key  abstractions  are  the  classes  and 
objects  which  correspond  to  the  vocabulary  of  the  problem  domain[Booch-1991:123]. 
The  mechanisms  are  structures  through  which  the  objects  interact  with  one  another 
to  provide  the  required  behavior[Booch  1991:123]. 

3.2.8  Identify  the  semantics  of  these  classes  and  objects.  This  step  “. . .  involves 
one  basic  activity,  that  of  establishing  the  meanings  of  the  classes  and  objects  iden¬ 
tified  from  the  previous  step”[Booch  1991:192].  This  entails  determining  what  can 
be  done  to  an  object,  and  what  things  the  object  can  do  to  other  objects.  According 
to  Booch,  “One  useful  technique  to  guide  these  activities  involves  writing  a  script 
for  each  object,  which  defines  its  life  cycle  from  creation  to  destruction,  including  its 
characteristic  behaviors”  [Booch  1991:192]. 


3.2. 3  Identify  the  relationships  among  these  classes  and  objects.  This  step 
establishes  the  interaction  of  things  within  the  system.  This  is  accomplished  by 
performing  two  related  activities:  “First  we  must  discover  patterns:  patterns  among 
classes,  which  causes  us  to  reorganize  and  simplify  the  system’s  class  structure,  and^ 


3-5 


CLASS  SPECIFICATION 


Class  Name:  Command 


Description:  Provides  the  command  abstraction  for  the  ATC  simulation. 


Static  Relationships 


hMattnbute 


Suffered  Operations 

Descriptive  Name 

Required  Operations 

Name  Applied  to 

Selectors:  GetJD 

Selectors: 

Is.StatU8 

Is.Termination 

IS.COMMAND 

Constructors:  Create.Command 

Constructors: 

Exceptions 

Name  Raised  by 

QA 

Invalid.Cmd  Command 

Initial: 

lQ\’a]id^ircraft  Command 

Figure  3.3.  Example  Object-Class  Specification 
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patterns  among  cooperative  collections  of  objects  which  lead  us  to  generalize  the 
mechanisms  already  embodied  in  the  design.  ...  Second,  we  must  make  visibility  de¬ 
cisions:  how  do  classes  see  one  another,  how  do  objects  see  one  another,  and,  equally 
important,  what  classes  and  objects  should  not  see  one  another” [Booch  1991:193]. 

3.2.4  Implement  these  classes  and  objects  This  step  requires  the  designer  to 
make  “. . .  design  decisions  concerning  the  representation  of  the  classes  and  objects 
we  have  invented,  and  allocating  classes  and  objects  to  modules,  and  programs  to 
processors” [Booch  1991:195].  The  result  of  this  step  is  a  complete  system  design. 
However,  new  abstractions  and  mechanisms  are  frequently  discovered  during  this 
step.  These  abstractions  usually  belong  to  a  lower  level  of  abstraction,  and  they 
are  designed  by  repeating  the  object-oriented  design  process.  When  no  lower  level 
abstractions  or  mechanisms  remain  to  be  designed,  the  design  at  higher  levels  can 
be  completed,  at  which  time  the  design  is  complete[Booch  1991:195]. 

S.S  Heuristics  for  determining  concurrency. 

As  noted  in  chapter  two,  Booch’s  Object-Oriented  Design  method  is  weak  in 
the  area  of  determining  concurrency.  Kelly  states  that  the  designer  is  given  "very 
little  guidance  on  concurrent  design  ...’’[Kelly  1987:245].  The  purpose  of  this  thesis 
is  to  provide  this  guidance. 

Following  are  four  heuristics  which  designers  may  use  in  determining  con¬ 
currency  in  object-oriented  designs.  They  are  based  on  the  heuristics  used  in  the 
DARTS,  LVM/OOD,  AD  ARTS,  and  Entity-life  Modeling  methods.  These  methods 
and  their  heuristics  are  summarized  in  chapter  two. 

3.3.1  Problem-space  concurrency.  An  object  which  models  concurrency 
in  the  problem  environment  should  be  implemented  as  a  task. 

According  to  Fairley,  “the  software  engineer  creates  models  of  physical  sit¬ 
uations  in  software”  [Fairley  1985:3].  One  of  the  strengths  of  the  object-oriented 
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paradigm  is  in  allowing  a  designer  to  create  these  models  of  physical  situations,  i.e., 
to  directly  model  the  problem-space,  thus  minimizing  the  “intellectual  distance” 
between  the  model  and  the  system  being  modeled[Fairley  1985:3].  Accordingly,  if 
concurrency  exists  in  the  problem-domain,  it  should  be  modeled  in  the  design. 

Concurrency  in  the  problem-domain  can  be  determined  by  identifying  behavior 
patterns,  or  sequences  of  events,  in  which  the  objects  participate.  These  sequences  of 
events  are  related  to  the  timing  and  ordering  of  the  operations  on  the  problem-space 
objects.  Sanden  states,  “while  an  object  does  not  control  the  timing  and  ordering 
of  the  operations  it  suffers,  the  timing  and  ordering  of  operations  on  various  objects 
can  be  described  as  behavior  patterns  in  the  reality” [Sanden  1990:17]. 

An  object  may  exhibit  a  single  pattern  of  behavior,  multiple  sequential  pat¬ 
terns,  or  none  at  all.  Note  these  patterns  of  behavior  specify  the  timing  and  ordering 
of  operations  required  of  the  object,  f.e.,  the  behavior  pattern  expresses  how  an  ob¬ 
ject  uses  other  objects.  Thus,  objects  with  no  suffered  operations  (an  actor  object 
in  Booch’s  terminologyfBooch  1987a:613]),  or  one  that  has  suffered  operations,  but 
requires  operations  of  other  objects  (an  agent  object  in  Booch’s  terminology[Booch 
1987a:613])  are  good  candidates  for  problem-space  concurrency.  On  the  other  hand, 
an  object  with  no  required  operations  (a  server  object  in  Booch’s  terminology[Booch 
1987a:615])  will  likely  not  exhibit  problem-space  concurrency,  although  it  may  or  may 
not  exhibit  concurrency  as  determined  by  the  remaining  heuristics. 

In  general,  no  priority  exists  among  the  heuristics,  f.e.,  which  heuristic  is  used 
to  determine  concurrency  is  not  important  as  long  as  the  necessary  concurrency 
is  identified.  In  a  sense,  however,  problem-space  concurrency  is  the  most  impor¬ 
tant  of  the  heuristics,  as  it  is  really  an  extension  of  the  object-oriented  philosophy; 
problem-space  concurrency  goes  to  the  heart  of  the  modeling  process.  By  examin¬ 
ing  the  beh&’vior  of  the  objects  specifically  to  identify  concurrency,  the  designer  not 
only  determines  problem-space  concurrency,  but  gains  a  better  understanding  of  the 
design  overall. 
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An  example  of  the  application  of  this  heuristic  is  in  the  air  traffic  control  simu¬ 
lation  (ATC)  described  in  chapter  four.  The  object  representing  the.ATC  simulation 
exhibits  multiple  behavior  patterns,  f.e.,  more  than  one  sequence  of  events.  The  ob¬ 
ject  needs  to  update  the  position  of  the  aircraft  in  the  control  space  at  periodic 
intervals,  while  concurrently  polling  the  keyboard  for  asynchronously  entered  com¬ 
mands.  The  keyboard  task  cannot  be  placed  within  the  update  comrol  space  without 
forcing  the  keyboard  task  to  be  periodic.  Thus  the  two  sequential  behavior  patterns 
require  two  tasks  to  maintain  the  asynchronous  nature  of  the  polling  routine. 

A  special  case  of  problem  space  concurrency  is  when  an  actual  hardware  device 
is  modeled  as  an  object.  In  general,  real-time  systems  interface  to  one  or  more 
hardware  devices;  these  devices  will  likely  be  modeled  as  objects,  with  the  operations 
corresponding  to  the  input/output  of  the  device. 

Devices  whose  primary  function  is  I/O,  e.<7.,  printers  and  keyboards,  have 
varying  speeds  and  will  generally  have  to  be  implemented  as  separate  tasks  to  ac¬ 
commodate  the  differences  in  speed.  In  particular,  if  the  I/O  device  must  interface 
with  another  task,  the  only  way  to  decouple  the  two  is  to  make  them  separate  tasks. 

Those  devices  which  perform  other  functions,  such  as  sensors  or  control  devices, 
may  or  may  not  be  implemented  as  tasks,  depending  on  how  they  interface  with  the 
rest  of  the  system.  If  the  device  provides  information  to  which  the  system  must 
respond,  but  provides  the  information  asynchronously,  then  a  task  should  monitor 
the  device  rather  than  having  the  system  poll  the  device. 

To  illustrate  this  point,  consider  a  system  that  contains  a  temperature  sensor. 
When  the  temperature  exceeds  some  limit,  the  system  must  take  action  to  reduce 
the  temperature.  If  the  system  polls  the  sensor,  system  resources  must  be  used  to 
monitor  a  condition  which  may  have  a  low  probability  of  occurring,  plus  the  polling 
interval  may  be  too  long  for  the  system  to  provide  adequate  response.  A  better 
solution  might  be  to  have  a  task  interface  with  the  sensor,  continuously  monitoring 
the  temperature.  When  the  task  detects  an  out-of-tolerance  condition,  it  alerts  the 
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system.  In  this  way,  the  system  need  not  dedicate  resources  to  a  polling  scheme,  and 
the  time  in  which  the  system  is  alerted  will  not  be  tied  to  a  polling  interval. 

3.5.2  Time  constraints.  An  object  whose  behavior  or  operations  are 
constrained  by  time  requirements  should  be  a  task. 

One  of  the  characteristics  of  real-time  systems  is  the  requirement  for  the  system 
to  meet  time  constraints.  These  time  constraints  can  be  periodic,  e.g.,  a  certain 
operation  needs  to  be  performed  at  periodic  intervals,  or  responsive,  as  when  the 
system  must  respond  to  an  event  within  a  certain  amount  of  time. 

In  an  object-oriented  design,  an  object’s  behavior  may  be  constrained  by  time 
requirements,  or  one  or  more  of  its  operations  may  be  so  constrained.  When  the 
designer  encounters  such  objects  or  operations,  the  objects  or  operations  should 
probably  be  implemented  as  tasks. 

An  example  of  a  periodic  constraint  could  be  a  temperature  monitor  which 
must  sample  a  temperature  sensor  at  regular  intervals;  this  would  most  likely  need 
to  be  a  separate  task.  An  example  of  a  response  constraint  is  an  interrupt  handler 
which  must  service  an  interrupt  within  d,  certain  time.  For  example,  in  an  elevator 
control  system,  an  interrupt  may  be  generated  when  an  elevator  arrives  at  a  floor, 
and  the  system  may  have  a  short  period  in  which  to  decide  to  stop  the  elevator  at 
the  floor  or  let  it  continue. 

3.3.3  Computational  requirements.  An  object  whose  behavior  or  oper¬ 
ations  require  substantial  computational  resources  should  be  a  task. 

Computational  requirements  may  dictate  that  some  operations  or  objects  be 
implemented  concurrently,  probably  as  low  priority,  background  tasks.  Occasionally, 
an  operation  requires  substantial  computational  resources.  For  example,  in  a  satellite 
communication  system,  the  satellite  object  may  have  an  operation  called  Calculate 
Satellite  Coordinates.  To  do  this  in  real  time  requires  the  integration  of  a  ninth- 
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order  polynomial.  Depending  on  the  resources  available,  this  could  be  quite  time 
consuming  and  processor  intensive.  This  operation  should  be  a  separate  task. 

S.S.4  Solution-space  objects.  An  object  introduced  in  the  software  so¬ 
lution  to  protect  a  shared  data  store,  decouple  two  interacting  tasks,  or 
synchronize  the  behavior  of  two  or  more  objects  should  be  a  task. 

Some  solution-space  objects  may  need  to  be  implemented  concurrently.  This 
is  a  general  heuristic  which  considers  concurrency  in  software  mechanisms  belonging 
to  the  solution  space. 

One  such  mechanism  is  a  shared  data  store  modeled  by  an  object.  The  only 
way  to  guarantee  nuitual  exclusion  in  Ada  is  to  use  a  task  with  a  selective  wait.  In 
this  case,  the  concurrency  is  forced  by  the  language  conventions. 

Another  mechanism  is  the  use  of  intermediary  tasks  to  control  the  coupling 
between  two  other  task.>.  Tn  a  simple  Ada  rendezvous  the  tasks  are  tightly  coupled; 
neither  task  can  continue  until  the  rendezvous  is  complete.  Oftentimes,  especially 
when  time  constraints  prevent  a  task  from  waiting,  another  task  can  be  introduced  to 
allow  the  other  two  to  proceed.  In  [Nielsen  and  Shumate  1989:16 1  several  types 
of  intermediaries  are  described,  combinations  of  which  allow  the  designer  to  achieve 
a  range  of  coupling,  from  very  loose  coupling  to  very  tight  coupling.  As  a  caveat, 
however,  the  looser  the  coupling,  the  greater  the  number  of  intermediaries  needed; 
this  could  generate  significant  tasking  o/erhead,  particularly  in  a  single-processor 
environment. 

A  third  mechanism  might  be  the  synchronization  of  two  objects  or  their  oper¬ 
ations.  In  this  case,  the  synchronizing  objects  or  operations  need  to  be  tasks,  with 
a  simple  rendezvous  accomplishing  the  synchronization. 
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S.4  Conclusion 

The  designer  of  object-oriented,  real-time  software  systems  has  little  more  than 
general  guidance  for  determining  which  objects  and  operations  to  make  concurrent. 
This  chapter  provided  four  heuristics  which  designers  can  use  to  make  concurrency 
decisions. 

The  next  chapter  provides  an  example  of  an  object-oriented,  real-time  system 
design,  an  air  traffic  control  simulation.  The  concurrency  heuristics  are  applied  to 
the  design  to  determine  the  concurrency  in  the  system. 
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IV.  Application  of  Concurrency  Heuristics 


In  this  chapter,  the  heuristics  for  determining  concurrency  presented  in  the 
previous  chapter  are  demonstrated  by  applying  them  to  a  sample  problem. 

■i.l  Design  Problem  Description 

Tiie  concurrency  heuristics  will  be  applied  to  the  design  of  an  air  traffic  control 
simulation,  whose  description  appeared  in  Creative  Computing,  c.1980.  For  brevity, 
the  system  will  be  referred  to  as  ATC.  Following  is  a  condensed  statement  of  the 
problem: 


Air  Traffic  Control  is  a  simulation  which  allows  the  user  to  play  the  part 
of  an  air  traffic  controller  in  charge  of  a  15x25  mile  area  from  ground 
level  to  9000  feet.  In  the  area  are  10  entry/exit  fixes,  2  airports  ,  and  2 
navaids.  During  the  simulation,  26  aircraft  will  become  active,  and  it  is 
the  responsibility  of  the  controller  to  safely  direct  these  aircraft  through 
his  airspace. 

The  controller  communicates  to  the  aircraft  via  the  scope,  issuing  com¬ 
mands  and  status  requests,  receiving  replies  and  reports,  and  noting  the 
position  of  the  aircraft  on  the  map  of  the  control  space.  The  controller 
issues  commands  to  change  heading  or  altitude,  to  hold  at  a  navaid,  or 
clear  for  approach  or  landing.  Each  aircraft  has  a  certain  amount  of  fuel 
left,  so  the  controller  must  see  to  it  that  the  aircraft  is  dispositioned  prior 
to  fuel  exhaustion.  Also,  the  minimum  separation  rules  must  be  followed, 
which  state  that  no  two  aircraft  may  pass  within  three  miles  of  each  other 
at  1000  feet  or  less  separation.  The  aircraft  must  enter  and/or  exit  via 
one  of  the  ten  fixes.  If  an  aircraft  attempts  to  exit  through  a  non-exit 
fix,  a  boundary  error  is  generated.  The  controller  may  request  a  status 
report  on  each  aircraft,  which  will  display  all  information  on  the  aircraft, 
including,  fuel  level,  which  is  measured  in  minutes. 

The  aircraft  can  be  one  of  two  types,  a  jet  or  a  prop.  The  jets  travel  at 
4  miles  per  minute,  while  the  props  travel  at  2  miles  per  minute.  This 
means  the  screen  must  updated  every  15  seconds  for  a  jet’s  course  to  be 
followed  accross  the  screen. 
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The  controller  dispositions  aircraft  by  giving  commands  which  enable  the 
aircraft  to  take  off,  land,  hold  at  a  navaid,  assume  a  landing  approach, 
turn,  or  change  altitude.  Take  off  is  accomplished  by  ordering  the  aircraft 
to  assume  a  certain  altitude;  there  is  no  ‘take  off’  command  as  such.  Each 
of  the  airports  has  restrictions  on  heading  for  takeoff;  these  restrictions 
must  be  observed.  Turns  and  altitude  changes  are  effectively  instanta¬ 
neous,  i.e.,  they  are  accomplished  at  the  next  mile  marker.  To  land, 
the  aircraft  must  be  cleared  for  landing  through  the  navigational  beacon 
(navaid)  assigned  to  the  airport.  Since  there  are  two  airports,  there  are 
two  navaids.  To  land,  the  controller  ph..  the  aircraft  on  a  heading  for 
a  navaid  and  issues  a  clearance  for  approach  command.  Once  the  air¬ 
craft  reaches  the  beacon,  it  automatically  assumes  the  correct  heading 
for  the  airport.  The  controller  then  issues  a  clearance  to  land  command, 
and  when  the  aircraft  reaches  the  airport  it  lands  (disappears  from  the 
screen).  If  the  controller  issues  a  hold  command,  the  aircraft  remains  at 
the  navaid  until  released. 

The  player  initially  specifies  the  length  of  the  simulation,  which  may  be 
between  16  and  99  minutes.  The  same  number  of  aircraft  will  appear 
for  each  run,  so  the  shorter  the  simulation,  the  more  challenging.  In  any 
session,  the  last  15  minutes  will  be  free  of  new  aircraft.  The  simulation 
terminates  when  all  aircraft  have  been  successfully  dispositioned,  the 
timer  runs  out,  the  player  requests  termination,  or  one  of  three  error 
conditions  occurs: 

•  conflict  error  -  separation  rules  were  violated 

•  fuel  exhaustion 

•  boundary  error  -  the  aircraft  attempt  to  leave  the  control  space  via 
an  unauthorized  point. 

Figure  4.1  contains  the  screen  layout  for  the  ATC  simulation.  The  *  symbol 
represents  a  navigational  aid,  the  %  and  #  are  airports,  and  the  numerals  are  entry- 
exit  fixes.  The  aircraft  are  represented  by  an  upper  case  letter  followed  by  a  number. 
The  letter  is  the  aircraft  identifier  and  the  number  is  the  altitude  of  the  aircraft  in 
thousands  of  feet;  e.g.,  ‘A4’  indicates  aircraft  ‘A’  is  at  4000  feet. 

ATC  commands  consist  of  either  three  character  directives  or  one  character 
status  requests.  To  request  a  status  on  a  particular  aircraft,  a  single  character 
reprsenting  the  aircraft  ID  is  entered.  Table  4.1  contains  a  summary  of  the  directive 
commands. 


A 

L 

R 

B 

clear  to  land 

hold  at  navaid 

continue  straight  ahead 

1 

ascend/descend  to  1000’ 

turn  left  45 

turn  right  45 

B 

ascend/descend  to  2000’ 

turn  left  90 

turn  right  90 

H 

ascend/descend  to  3000’ 

turn  left  135 

turn  right  135 

11 

ascend/descend  to  4000’ 

turn  left  180 

turn  right  180 

B 

ascend/descend  to  5000’ 

clear  for  approach 

clear  for  %  approach 

Table  4.1.  ATC  Commands 
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Figure  4.1.  Airspace  Display 
4.2  Top  Level  of  Abstraction 

A  cursory  reading  of  the  problem  statement  suggests  several  key  abstractions: 
aircraft,  airspace,  display,  commands,  messages,  etc.  The  initial  focus  of  the  design 
is  determining  which  of  these  key  abstractions  belong  at  the  top  level  of  abstraction. 
This  is  admittedly  a  matter  of  designer  judgement,  but,  in  general,  the  top  level 
should  contain  a  minimal  set  of  objects  and  classes,  while  still  encumpassing  the 
entire  system. 

In  some  cases,  the  top  level  of  abstraction  may  consist  of  a  single  object,  such  as 
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ATO 


Figure  4.2.  Initial  Top  Level  Object  Diagram 


in  Booch’s  example  of  a  home  heating  system[Booch  1991:222-280].  In  this  instance, 
the  top  level  of  abstraction  is  the  object  theHomeHeatingSystem.  It  could  be  argued 
that  the  ATC  system  is  similar,  so  the  top  level  would  contain  only  an  ATC  object. 
However,  this  is  not  a  very  useful  structure,  since  it  doesn’t  really  say  much  about 
the  ATC  system  or  provide  much  guidance  on  what  the  next  step  may  be.  So  for 
this  design,  the  top  level  will  contain  more  than  one  object. 

4.2.1  Identify  the  classes  and  objects.  As  Figure  4.2  illustrates,  the  top  level 
of  abstraction  consists  of  an  ATC  object,  a  console  object,  and  a  command  clciss. 
This  particular  breakdown  Wcis  chosen  because  the  problem  statement  indicated  two 
major  activities  of  the  system:  periodic  updating  of  the  display  screen  to  represent 
aircraft  movement  in  the  airspace,  and  responding  to  commands  entered  by  the 
controller. 

Figure  4.2  captures  the  essence  of  this  activity:  the  ATC  object  does  some¬ 
thing  with  commands  and  does  something  with  the  operator’s  console.  The  lines 
connecting  objects  are  at  this  time  undirected;  the  arrows  will  be  added  when  the 
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relationships  are  established. 

Notice  that  since  there  is  a  single  instance  of  both  the  ATC  abstraction  and 
the  console  abstraction,  they  are  specified  as  objects.  There  could,  and  most  likely 
will,  be  many  instances  of  the  command  abstraction,  so  it  is  specified  as  a  class. 
This  distinction  is  not  reflected  in  the  figures. 

4.2.2  Identify  the  semantics  of  the  classes  and  objects.  This  step  involves 
specifying  the  behavior  of  the  objects  and  classes  at  the  current  level  of  abstraction. 

4.2.2. 1  The  command  class.  The  command  class  is  rather  straightfor¬ 
ward.  It  exports  objects  of  type  Command  (whose  representation  is  as  yet  unspecified) 
and  two  kinds  of  operations.  The  Great e_Command  operation  accepts  a  character 
string  and  returns  the  command  corresponding  to  the  string.  The  other  kind  of 
operation,  a  set  of  selectors,  accepts  commands  as  input  and  then  returns  true  if  the 
command  corresponds  to  that  selector,  and  false  otherwise.  For  example,  if  a  turn 
command  is  passed  to  Is_Turn,  then  true  will  be  returned,  but  if  change  altitude 
is  passed  to  the  same  operation,  false  will  be  returned.  Thus,  the  command  class 
exhibits  no  dynamic  behavior  and  can  be  implemented  as  a  set  of  rather  simple  func¬ 
tions.  The  object-class  specification  for  the  Command  class  is  shown  in  Figure  4.3. 

4. 2. 2. 2  The  console  object.  Since  the  console  is  an  object  and  not  a 
class  of  objects,  it  does  not  export  a  type;  it  does,  however,  export  operations  on 
the  console  object. 

As  with  the  command  class,  the  console  object  does  not  exhibit  significant 
dynamic  behavior  over  time.  This  does  not  mean,  however,  that  there  is  no  concur¬ 
rency  withing  the  console  object.  At  this  level,  the  console  displays  messages  and 
retrieves  input  from  the  user.  Lower  levels  of  abstraction  may  reveal  concurrency 
which  is  not  visible  from  the  higher  levels. 
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CLASS  SPECIFICATION 

IClass  Name:  Command 


Description:  I^jovidcs  the  command  abstraction  for  the  ATC  simulation. 


Static  Relationships 


Suffered  Operations 
Descriptive  Name 


Selectors:  GetJD 


(Selectors: 


Dynamic  Relationships 


Required  Operations 
Name  Applied  to 


IsJStatus 

Is.Termination 


Is-COMMAND 

Constructors:  Create.Cortunand 


Name  Raised  by 

Invalid.Cmd  Command 

Invalid^ircrafl  Command 


{Constructors: 


Exceptions 


t 


J 

Initial: 


Figure  4.3,  Command  Class  Object-Class  Specification 
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The  following  types  of  input/output  from  the  console  can  be  identified  from 
the  problem  statement: 


•  Output  the  time  remaining 

•  Output  a  map 

•  Output  a  preview  message 

•  Output  the  string  “Roger” 

•  Output  the  input  string 

•  Input  a  string 

Whether  these  operations  can  be  combined  into  a  smaller  set  or  not  cannot 
be  determined  at  this  time.  The  object-class  specification  for  the  console  object  is 
contained  in  Figure  4.4. 

4.S.S.3  The  ATC  object  As  with  the  console  object,  the  ATC  object 
exports  no  type,  but  neither  does  ATC  export  any  operations.  Since  it  is  the  very  top 
level  of  the  system,  no  object  can  call  it,  unless  the  user  entering  a  “run”  command 
via  the  operating  system  is  considered  an  operation[Seidewitz  1989:99). 

Since  the  ATC  exports  neither  type  nor  operation,  it  must  require  operations 
from  other  objects  (else  it  would  not  be  much  of  an  object).  Thus  to  determine 
the  behavior  of  the  object  entails  identifying  the  time  ordering  and  frequency  of  the 
required  operations,  and  the  threads  of  control.  Even  at  this  high  level,  the  concur¬ 
rency  heuristics  outlined  in  chapter  three  can  be  applied;  however,  any  concurrency 
discovered  here  should  be  considered  “candidate”  concurrency,  as  further  refinement 
could  feasibly  push  the  concurrency  further  down  the  hierarchy. 

To  elaborate  the  behavior  of  ATC,  the  life  of  the  object  will  be  modeled, 
as  recommended  by  Booch[Booch  1991:192).  Since  the  user  selects  how  long  the 
simulation  is  to  run,  this  information  will  have  to  be  retrieved.  In  addition,  the  map 
will  have  to  be  initially  drawn.  These  two  items  make  up  the  initialization  of  the 
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CLASS  SPECIFICATION 


Glut  Name:  Console 


Description;  This  object  provides  the  I/O  abstraction  for  the  ATC  simulation. 


Static  Relationships 


Dynamic  Relationships 


Suffered  Operations 
Descriptive  Name 


Requited  Operations 
Name  Applied  to 


DispJrevJlsg 

Constructors;  DispJ’rev.Msg 

Display 

Disp.AIapJtem 

Disp.MspJtcm 

Display 

Disp.Time 

Disp.Time 

Display 

DijpJnput 

DispJnput 

Display 

DispJlogei 

Dispjfoger 

Display 

'GeUnput 

GetJnput 

Keyboard 

Name 


Raised  by 


Exceptions 


QA 

Initial;  '' 


Figure  4.4.  Console  Object-Class  Specification 

system;  once  the  initialization  is  complete,  at  least  two  independent  threads  of  control 
are  suggested  by  the  problem  statement.  One  thread  handles  the  input  of  commands 
from  the  user  and  the  execution  of  these  commands;  this  is  an  asynchronous  thread 
since  the  user  can  enter  commands  at  any  time.  Another  thread  is  a  periodic  update 
of  the  aircraft  position  in  the  airspace  and  the  subsequent  display  of  the  updated 
map  on  the  console.  When  either  of  these  threads  terminates,  the  simulation  ends. 
No  special  clean-up  operations  are  required  other  than  displaying  an  appropriate 
termination  message.  The  script  of  the  ATC  object  is  shown  in  Figure  2.5. 

Applying  the  concurrency  heuristics  to  these  threads  of  cohtrol  yields  two  tasks. 
The  periodic  update  of  the  display  fits  the  time  constraint  heuristic  and  thus  should 
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Get  Simulation  Length 
Draw  Initial  Map 


loop 

Get  User  Input 
If  Termination  Request  Then 
Terminate  Simulation 
End  If 

Create  Command 
Process  Command 
end  loop 

Clean 


loop 

Delay  15  Seconds 
Get  Airspace  Updates 
Display  Airspace  Updates 
end  loop 


Up 


Figure  4.5.  Script  for  the  ATC  Object 

be  a  separate  task.  The  processing  of  commands  is  an  asynchronous  behavior  pat¬ 
tern,  indicating  it  should  be  contained  in  a  concurrent  task.  The  command  process¬ 
ing  function  cannot  be  embedded  within  the  periodic  update  task  without  forcing 
the  command  processing  task  to  be  periodic  as  well.  Therefore,  the  command  pro¬ 
cessing  function  should  be  a  separate  task  under  the  problem-space  heuristic.  The 
object-class  specification  for  the  ATC  object  is  in  Figure  2.6 

4.S.3  Identify  the  relationships  among  the  classes  and  objects.  This  step  iden¬ 
tifies  patterns  of  object  interaction  and  visibility  between  objects  and  classes.  The 
behavior  specification  from  the  previous  step  is  used  to  determine  the  relationships. 
Examining  the  command  class  and  the  console  object  reveals  no  interaction,  at  least 


two  objects  need  see  no  other  objects. 


The  ATC  object,  on  the  other  hand,  needs  to  have  both  command  and  console 
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CLASS  SPECIFICATION 


Iciau  Name:  ATC 


iDescription;  This  is  the  main  object  of  the  simulation.  It  controls  the  interaction  of  the  other  objects. 


Static  Relationships 


Dynamic  Relationships 


Suffered  Operations 
Descriptive  Name 


ISelectors: 


IConstructors: 


Required  Operations 
Name  Applied  to 


lelectors;  GetJD  Command 

Is.Status  Command 

Is.Temunation  Command 
ls.CO.MMANO  Command 

onstructors;  DispJ’re..Mge  Console 
DispAfapJtem  Console 
Disp.Time  Console 
DispJnput  Console 
DispJtoger  Console 
GetJnput  Console 
Create.Cmd  Command 


Name  Raised  by 

TimeJixpited  ATC 

Invalid.Cmd  Command 

Invalid.Acft  Command 

FuelJixhausted  Airspace 

Conflict^rror  Airspace 

Bdary^rror  Airspace 


Exceptions 


Figure  4.6,  ATC  Object-Class  Specification 
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ATC 


visible.  This  is  apparent  from  the  script  of  the  ATC  behavior  in  Figure  4.5.  Both 
console  operations  (get  input  string)  and  command  operations  (convert  string  to 
a  command)  are  used.  Other  operations:  on  objects  not  yet  elaborated  are  also 
referenced,  but  they  belong  to  lower  levels  of  abstraction.  The  final  top-level  object 
diagram,  with  visibility  indicated  by  directed  lines,  is  in  Figure  4.7.  The  update 
airspace  task  is  indicated  by  the  parallelogram  within  the  ATC  object. 

4-2. 4  Implement  the  classes  and  objects.  It  is  at  this  time  that  representation 
decisions  are  made  and  the  operations  on  each  object  are  implemented.  However,  the 
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implementation  cannot  be  completed  until  all  lower  level  abstractions  are  likewise 
implemented.  This  is  a  result  of  the  iterative  nature  of  object-oriented  design:  the 
same  process  is  applied  many  times  at  different  abstraction  levels. 

In  implementing  the  ATC,  console,  and  command  objects,  unspecified  abstrac¬ 
tions  are  encountered,  necessitating  suspension  of  the  implementation  while  these 
new  abstractions  are  designed.  Once  implemented,  the  suspended  implemenations 
may  resume. 

Subsequent  sections  in  this  chapter  detail  this  refinement  for  the  ATC  and 
console  objects,  but  an  example,  which  allows  the  command  class  to  be  completed, 
is  given  here  for  clarity. 

The  problem  statement  and  ATC  script  both  refer  to  input  from  the  user 
which  commands  the  aircraft  or  request  status.  As  yet,  there  is  not  an  input  string 
object,  and  this  needs  to  be  specified  before  the  command  class  can  be  completed. 
The  input  string  class  is  deemed  to  be  a  component  object  of  the  console  object,  so 
this  class  appears  beneath  the  console  in  the  composition  hierarchy.  However,  the 
command  class  and  the  ATC  object  need  visibility  into  the  input  string  object.  Thus 
in  the  object  diagram,  shown  in  Figure  4.7,  directed  lines  are  drawn  from  ATC  and 
command  to  input  string.  The  command  class  may  now  be  completed. 

4-3  Refinement  of  the  console  object. 

In  the  remainder  of  this  chapter  the  discussion  will  be  more  informal  than 
previous  sections.  The  focus  will  be  on  concurrency  in  the  ATC;  the  steps  in  the 
Object-Oriented  Design  method  will  be  followed,  but  the  design  will  not  be  docu¬ 
mented  to  the  level  of  detail  of  the  previous  section. 

As  stated  previously,  the  console  object  has  five  output  operations  and  one 
input  operation.  These  operations  could  be  implemented  at  this  time,  given  a  suit¬ 
able  display  interface  package,  excepting  that  the  problem  statement  places  some 
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restrictions  cn  the  format  of  the  display.  In  effect,  the  display  is  divided  into  five 
distinct  areas: 

•  Time  area 

•  Preview  area 

•  Map  area 

•  Input  area 

•  Response  area 

These  areas  can  be  treated  as  component  objects  of  the  console.  They  will 
consist  of  a  location  on  the  console  and  two  operations:  display  message  and  clear 
area. 

Since  the  output  has  been  divided  into  five  separate  objects,  the  input  opera¬ 
tion  will  become  an  object  to  maintain  separation  of  concerns.  In  light  of  this,  it  is 
appropriate  to  form  two  component  objects  of  console:  display  and  keyboard.  The 
display  areas  mentioned  earlier  have  now  become  component  objects  of  the  display 
object.  This  arrangement  is  shown  in  Figure  4.8. 

At  this  level  the  concurrency  heuristics  can  be  applied  to  determine  the  key¬ 
board  object  to  be  concurrent.  It  is  a  hardware  device  being  modeled  in  software, 
and  so  should  be  implemented  concurrently. 

The  implementation  of  the  display  areas  must  now  be  considered  and  a  problem 
immediately  poses  itself.  Should  each  area  object  write  directly  to  the  display  or 
should  each  call  a  screen  object  which  alone  accesses  the  physical  device?  In  the 
interests  of  encapsulation,  the  screen  object  option  is  chosen,  although  the  resulting 
object  diagram  looks  rather  odd  with  the  display  being  split  into  five  component 
objects  and  then  all  five  running  back  into  one  screen  object. 

The  next  concern  is  with  concurrency.  Since  the  screen  is  a  hardware  device 
being  modeled  in  software,  the  screen  object  is  concurrent. 
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The  final  console  object  diagram  appeal’s  in  Figure  4.9. 


4-4  Refinement  of  the  ATC  object. 

The  top  level  design  has  considered  mainly  the  user  interface,  i.e.,  handling 
of  input,  display  of  output,  and  processing  of  commands.  The  Command  class  has 
been  designed  and  the  Console  has  been  refined;  this  leaves  the  ATC  object  which 
is  the  heart  of  the  simulation. 

Examining  the  script  from  the  ATC  object  in  Figure  4.5  reveals  references  to 
the  Airspace  object.  Thus,  initially,  the  ATC  object  includes  the  Airspace  object, 
as  shown  in  Figure  4.10.  The  airspace  is  basically  a  3-dimensional  area  through 
which  aircraft  fly  and  containing  certain  landmarks  (navigational  beacons,  airports, 
entry/exit  fixes).  The  operations  on  the  Airspace  object  include  setting  and  getting 
the  position  of  landmarks,  getting  the  position  of  a  particular  aircraft,  and  iterating 
through  all  the  aircraft  in  the  airspace  to  get  their  positions.  It  is  possible  to  cast 
this  last  operation,  iterating  through  all  aircraft,  as  a  task;  however,  by  the  first 
heuristic,  the  Airspace  object  has  no  discernible  behavior  pattern  in  the  problem- 
space.  It  is  rather  a  passive  entity  through  which  aircraft  fly.  So  the  decision  at  this 
point  is  to  not  make  the  Airspace  or  any  of  its  operations  concurrent. 

One  practical  matter  that  arises  is  the  communication  between  the  ATC  object 
and  the  Airspace  object.  The  script  of  the  ATC  object  indicates  ATC  “retrieves 
airspace  updates”  and  then  displays  them.  This  implies  the  need  for  a  ‘solution- 
space’  object,  a  list  of  aircraft  updates  which  the  Airspace  returns  to  the  ATC 
object.  As  this  object  is  written  only  by  Airspace  and  read  only  by  ATC,  it  need  not 
be  a  protected  data  store,  and  consequently  should  not  be  implemented  ae  a  task. 
This  object,  the  Update_RecordJ.ist  is  shown  in  Figure  4.11. 

The  next  step  in  refining  the  ATC  object  is  to  examine  the  component  objects 
of  the  Airspace.  The  landmark  objects  are  static,  i.e.,  they  are  initialized  at  the 
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Figure  4.11.  ATC  with  Update_Recordiist 
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start  of  the  simulation  and  never  change  location,  so  these  objects  are  considered 
non-concurrent  (Figure  4.12). 

This  leaves  the  Aircraft  class.  This  class  has  a  definable  behavior  pattern  v/hich 
changes  over  time.  An  aircraft  is  created,  takes  off  or  enters  the  airspace  through 
a  fix,  makes  changes  to  its  altitude  or  course,  and  either  lands  or  exits  through  a 
fix.  iS  the  Aircraft  class,  according  to  the  first  heuristic,  exhibits  problem-space 
concurrency  and  should  be  concurrent  in  the  design. 

An  objection  that  may  be  raised  at  this  point  is  that  with  twenty-six  aircraft, 
this  leads  to  massive  concurrency  which  may  not  be  feasible  on  a  single  processor 
system.  This  is  a  valid  objection,  but  is  really  an  implementation  issue.  The  implc- 
menter  may  decide  to  limit  the  number  of  t;isks  in  any  way  he  or  she  chooses;  the 
main  concern  for  the  designer  is  in  modeling  the  problem-space  and  hence  identifying 
concurrency. 

The  Aircraft  class  has  a  number  of  component  chisses  and  objects,  but  these 
are  considered  attributes  of  the  aircraft  and  arc  thus  not  concurrent  (Figure  4.13). 

4.5  Summary 

This  chapter  has  applied  the  concurrency  heuristics  to  an  Air  Traffic  Control 
Simulation.  Five  concurrent  tasks  were  identified:  two  in  the  ATC  object,  a  keyboard 
task,  a  display  task,  and  the  Aircraft  task. 
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V.  Validation  of  Concurrency  Heuristics 


This  chapter  presents  a  plan  for  determining  the  validity  of  the  concurrency 
heuristics  developed  in  the  first  four  chapters.  A  brief  discussion  of  validation  meth¬ 
ods  is  given  first,  followed  by  a  detailed  description  of  the  method  used  to  validate 
the  concurrency  heuristics  given  in  this  thesis,  concluding  with  the  results  of  the 
validation. 


5.1  Validation  Methods 


Research  results  may  be  validated  by  three  methods:  analytical,  empirical, 
and  expert  opinion.  Analytical  validation  seeks  to  establish  the  research  results  by 
proving  the  results  follow  from  established  principles  or  concepts,  much  the  same  as 
a  mathematician  proves  a  theorem  using  axioms,  postulates,  and  previously  proven 
theroems.  While  this  method  is  the  most  rigorous  of  the  three,  it  is  also  the  most 
difficult  to  apply  in  the  software  engineering  arena.  The  reason  for  this  is  that 
there  are  few,  if  any,  widely  accepted  principles  from  which  to  prove  further  results. 
Those  principles  that  do  seem  to  be  established,  such  as  high  cohesion,  low  coupling, 
information  hiding,  etc.,  have  not  themselves  been  proven  analytically  or  empirically, 
but  are  rather  accepted,  or  so  it  seems,  based  on  expert  opinion  (the  third  method). 


Empirical  validation  is  based  either  on  observation  of  naturally  occurring  phe¬ 
nomena,  or  on  a  controlled  experiment  designed  to  demonstrate  the  truth  or  false- 
hhod  of  a  concept.  Again,  software  engineering  principles  do  not  easily  yield  to 
empirical  validation,  mainly  because  the  phenomena  to  be  observed  are  usually  in¬ 
tangible.  For  example,  the  superiority  of  a  data  compression  algorithm  may  be 
demonstrated  by  implementing  it  and  comparing  its  pei  for  induce  against  other  data 
compression  algorithms.  However,  a  theory  of  software  modularization  cannot  be 
demonstrated  simply  by  applying  the  theory  in  implementing  a  system,  as  the  pro¬ 
cess  of  applying  the  theory  is  subjective-each  designer  will  apply  it  a  little  differently 
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in  all  but  the  most  trivial  cases.  Consequently,  implementing  the  ATC  simulation 
described  in  chapter  four  using  the  concurrency  heuristics  says  nothing  about  the 
validity  of  the  heuristics. 

The  final  validation  method  is  expert  opinion,  in  which  experts  in  the  field 
evaluate  the  research  results  and  provide  their  considered  opinion  on  the  validity 
of  the  results.  This  is  admittedly  a  subjective  process,  but  it  does  provide  some 
condidence  in  the  research  and  is  certainly  better  than  no  validation  at  all. 

5.2  Validation  Approach  for  Concurrency  Heuristics 

The  validation  method  chosen  for  this  thesis  is  expert  opinion.  The  concur¬ 
rency  heuristics,  a  summary  of  the  design  of  the  ATC  simulation,  and  a  questionaire 
were  distributed  to  fourteen  experts.  The  experts  were  chosen  based  on  their  expe¬ 
rience  with  object-oriented  design.  Of  the  fourteen,  11  responded.  The  validation 
package  and  the  experts’  responses  appear  in  Appendix  B. 

5.3  Validation  Results 

For  convenience  the  concurrency  heuristics  questionaire  is  shown  in  Figure  5.1, 
with  the  results  summarized  in  Table  5.1.  Each  question  in  the  questionaire  will  be 
discussed  in  turn. 


Question 

Mean 

Std  Dev 

Ideal 

1 

4.1 

.7 

5.0 

2 

4.4 

.8 

5.0 

3 

1.5 

.5 

1.0 

4 

2.1 

.8 

1.0 

5 

1.2 

.4 

1.0 

Table  5.1.  Questionaire  Results 


Question  one  was  necessary  to  ensure  the  experts  understood  what  was  being 
presented.  Most  of  the  experts  felt  the  heuristics  were  understandable  (average  4.1 
out  a  possible  5.0),  although  some  commented  that  heuristic  one  was  rather  vague. 
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1.  Are  the  heuristics .understandable? 

1  2  3  4  5 

NO  FAIRLY  YES 


2.  Do  the  heuristics  help  the  designer  in  meiking  concurrency  decisions? 
1  2  3  4  5 

NO  SOME  YES 


3.  Are  there  concurrency  situations  not  covered  by  the  heuristics?  Which? 
1  2  3  4  5 

NONE  SOME  MANY 


4.  Is  there  overlap  among  the  heuristics?  Which? 
1  2  3  4  5 

NONE  SOME  MANY 


5.  Do  the  heuristics  violate  established  principles  of  software  engineering 
(coupling,  cohesion,  encapsulation,  information  hiding,  etc.)?  Which? 

1  2  3  4  5 

NONE  SOME  MANY 


Figure  5.1.  Expert  Opinion  Questionaire 
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The  first  heuristic  deals  with  building  a  model  of  real-world  objects,  which  is  a  rather 
vague  concept  in  itself,  at  least  in  application.  The  other  heuristics  seem  to  be  more 
concrete,  corresponding  to  concepts  that  are,  for  the  most  part,  more  familiar  to 
designers. 

Question  two  was  probably  the  most  important,  at  least  to  the  author.  The 
purpose  of  the  thesis  was  to  provide  guidance  to  designers;  this  question  gives  an 
indication  whether  or  not  this  purpose  was  realized.  The  average  response  of  4.4  out 
of  5.0  indicates  the  experts  felt  the  heuristics  were  helpful  to  designers,  flowever, 
several  comments  provided  insight  into  the  usefulness  of  the  heuristics. 

One  comment  concerned  the  amount  of  detail  in  the  explanation  of  the  heuris¬ 
tics,  i.e.,  more  detail  weis  needed  to  make  the  heuristic  really  useful.  The  validation 
package  contained  only  a  skeleton  explanation  of  the  heuristics  (see  Appendix  B); 
more  detail  is  contained  in  chapter  three. 

Another  person  noted  that  use  of  the  wrong  heuristic  could  lead  to  massive 
concurrency  in  the  solution;  for  example,  in  the  ATC  problem,  twenty-  six  tasks 
would  be  produced  by  applying  heuristic  one  to  the  Aircraft  object,  whereas  one 
aircraft  manager  task  could  be  derived  from  heuristic  three  or  four.  In  a  single¬ 
processor  system  the  massive  concurrency  could  lead  to  excessive  teisking  overhead, 
in  which  case  the  second  option,  that  of  a  single  task  managing  the  concurrency 
in  all  the  aircraft,  might  be  preferable.  However,  this  is  done  at  the  sacrifice  of 
the  integrity  of  the  model,  since  adhering  to  heuristic  one  more  closely  models  the 
problem  space  than  do  the  other  heuristics.  These  sorts  of  tradeoffs  are  normal  in 
software  design;  the  heuristics  allow  the  designer  to  identify  the  concurrency,  and, 
consequently,  the  areas  where  these  tradeoffs  exist. 

Questions  three  was  a,  completeness  question.  To  be  usefule,  a  set  of  heuristics 
must  be  complete,  i.e.,  it  must  identify  all  possible  concurrency  situations.  While 
none  of  the  experts  were  willing  to  subscribe  to  such  a  strong  statement,  none  came 
up  with  any  situations  not  covered  by  the  heuristics. 
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Question  four  addressed  the  issue  of  redundency  in  the  heuristics,  whether 
more  than  one  heuristic  could  apply  to  the  same  situation.  All  agreed  there  is  some 
overlap  among  the  heuristics,  but  not  a  gioat  deal  (average  response  of  2.1  with  an 
ideal  of  1.0).  Some  commented  that  redundency  is  not  a  real  problem;  the  important 
matter  is  that  the  concurrency  be  identified.  This  is  probably  true  in  general,  but 
returning  to  the  discussion  on  question  three,  there  may  be  situations  where  the 
overlap  is  actually  desirable.  In  determining  concurrency  in  the  Aircraft  object,  two 
heuristics  were  applied  and  resulted  in  different  designs,  the  choice  of  which  had 
significant  impact  on  the  conceptual  integrity  of  the  design  as  well  as  potentially 
affecting  the  performance  of  the  implementation.  In  this  case  the  overlap  among  the 
heuristic  gave  the  designer  more  flexibility  to  make  design  tradeoffs. 

Question  five  is  important  from  an  overall  software  engineering  standpoint, 
since  any  heuristics  which  violate  accepted  practice  will  likely  not  be  accepted.  On 
this  question  the  experts  averaged  a  1.2  with  1.0  being  the  ideal. 

5.4  Conclusion 

The  results  of  the  questionaire  were  very  encouraging.  The  prevailing  opinion 
among  the  experts  was  that  the  heuristics  are  helpful  to  designers,  understandable, 
and  complete.  From  this  we  may  conclude  that  the  heuristics  appear  to  be  sound. 
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VI.  Conclusions  and  Recommendations 


6.1  Summary 

The  purpose  of  this  thesis  was  to  develop  heuristics  for  determining  concur¬ 
rency  in  object-oriented  designs  of  real-time  systems.  This  was  accomplished  by 
first  investigating  heuristics  available  to  real-time  designers  using  other  paradigms 
(Structured  Analysis,  Jackson  System  Development)  and  then  examining  the  object- 
oriented  approach  to  see  where  these  existing  heuristics  may  apply.  The  survey  of 
existing  heuristics  is  contained  in  chapter  two,  and  the  heuristics  for  object-oriented 
design  are  in  chapter  three. 

In  real-time  design  using  Structured  Design  techniques,  the  heuristics  for  deter¬ 
mining  concurrency  are  based  on  the  functional  decomposition  of  the  system[Gomaa 
1984].  Consequently,  the  heuristics  consider  such  things  as  functional  cohesion,  tem¬ 
poral  cohesion,  process  abstraction,  etc.,  which  are  not  compatible  with  object- 
oriented  design.  However,  some  of  the  heuristics,  in  particular  the  ones  dealing 
with  periodic  execution  and  response  to  events  within  time  constraints,  do  apply  to 
object-oriented  design. 

Jackson  System  Development  (JSD)  takes  a  modeling  perspective  in  designing 
software  systems,  which  is  similar  to  the  object-oriented  approach[Cameron  1986]. 
JSD  does  not  specifically  address  determining  concurrency  in  real-time  systems,  but 
a  derivative  method,  Entity-Life  Modeling[Sanden  1989],  does  provide  principles  for 
determining  concurrency.  In  Entity-Life  Modeling  the  system  is  characterized  as  a 
set  of  sequential  behavior  patterns  in  which  the  entities  or  objects  comprising  the 
system  participate.  Each  separate  behavior  pattern  is  then  considered  a  concurrent 
task  in  the  design. 

Object-oriented  design  models  the  system  under  consideration  as  a  set  of  ob¬ 
jects  and  the  operations  on  those  objects.  The  system  is  implemented  by  specifying 
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the  interaction  of  the  objects,  i.e.,  the  timing  and  ordering  of  the  operations.  The 
method,  as  presented  by  Boov.h[Booch  1991],  does  not  provide  heuristics  for  deter¬ 
mining  concurrency.  Booch’s  method  is  summarized  in  chapter  three. 

The  heuristics  of  Gomaa[Gomaa  1984]  and  the  Entity-Life  Modeling  princi- 
ple[Sanden  1989]  were  applied  to  the  object-oriented  approach  to  produce  a  set  of 
heuristics  to  guide  designers  in  determining  concurrency  in  the  design  of  real-time 
systems.  The  four  heuristics  are: 

1.  Problem-space  concurrency.  An  object  which  models  concurrency  in  the 
problem  environment  should  be  implemented  as  a  task.  Concurrency  in  the 
problem-domain  can  be  determined  by  identifying  behavior  patterns,  or  se¬ 
quences  of  events,  in  which  the  objects  participate.  These  sequences  of  events 
are  related  to  the  timing  and  ordering  of  the  operations  on  the  problem-space 
objects. 

This  concept  is  closely  related  to  the  Entity-Life  Modeling  principle,  the  dis¬ 
tinction  being  that  object-oriented  design  focuses  on  individual  objects  and 
their  operations,  whereas  Entity- Life  Modeling  concentrates  on  identifying  be¬ 
havior  patterns  in  which  any  number  of  objects  may  participate.  Thus,  Entity- 
Life  Modeling  partitions  the  concurrency  based  on  the  behavior  patterns,  which 
may  include  any  number  of  objects.  The  object-oriented  approach  partitions 
the  concurrency  according  to  the  objects  which  contain  the  behavior  patterns. 

2.  Time  constraints.  An  object  whose  behavior  or  operations  are  constrained 
by  time  requirements  should  be  a  task.  This  heuristic  combines  the  timing 
related  heuristics  of  Gomaa[Gomaa  1984]  and  Nielsen  and  Shumate[Nielsen 
and  Shumate  1989].  Thus  an  operation  that  is  invoked  at  regular  intervals  is 
considered  a  separate  task  (in  structured  design  these  are  periodic  functions). 
Also,  an  operation  which  must  respond  to  an  event  within  a  certain  time  period 
is  a  task,  for  example,  an  operation  invoked  in  response  to  an  interrupt. 
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3.  Computational  requirements.  An  object  whose  behavior  or  operations 
require  substantial  computational  resources  should  be  a  task.  These  tasks 
would  most  likely  run  in  background  at  a  low  priority. 

4.  Solution-space  objects.  An  object  introduced  in  the  software  solution  to 
protect  a  shared  data  store,  decouple  two  interacting  tasks,  or  synchronize  the 
behavior  of  two  or  more  objects  should  be  a  task.  Booch  calls  these  ‘mecha¬ 
nisms’,  i.e,,  objects  with  no  counterpart  in  the  problem-space,  but  which  are 
necessary  to  implement  the  system  on  a  real  machine.  A  n  example  would  be 
a  shared  data  store  implemented  in  Ada;  a  task  must  be  used  to  guarantee 
mutual  exclusion. 

6.2  Conclusions 

The  concurrency  heuristics  are  powerful  tools  for  determining  concurrency  in 
object-oriented  design  of  real-time  systems.  The  set  of  heuristics  is  small  enough  to 
be  easily  remembered,  yet  general  enough  to  determine  concurrency  in  most  cases. 
The  heuristics  are  easy  to  understand  and  apply,  and,  in  some  cases,  they  allow  the 
designer  to  determine  concurrency  from  different  perspectives,  allowing  the  designer 
a  range  of  choices  in  the  implementation. 

While  the  heuristics  are  referred  to  as  ‘design’  heuristics,  they  actually  can  be 
useful  during  a  broader  portion  of  the  development  life-cycle  than  just  the  design 
phase.  In  object-oriented  design,  the  analysis,  design,  and  implementation  stages  are 
not  rigidly  delineated;  rather,  they  are  actually  a  continuum  in  which  the  software 
model  progresses  from  a  more  abstract  representation  (analysis)  to  a  more  concrete 
representation  (implementation).  The  heuristics  may  be  applied  at  any  point  on 
the  continuum.  For  example,  in  the  ATC  problem,  concurrency  was  determined 
in  the  ATC  object  very  early  in  the  analysis;  in  fact  it  can  be  determined  from 
the  requirements  definition.  The  concurrency  in  the  console  object,  however,  was 
determined  after  the  object  had  been  almost  completely  designed.  The  problem- 
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space  heuristic,  by  its  very  nature,  does  not  determine  concurrency  until  late  in  the 
process,  perhaps  not  until  detailed  design. 

Using  object-oriented  design,  a  designer  seeks  to  build  a  model  of  the  problem- 
space,  i.e.,  the  structure  of  the  solution  should  reflect  the  structure  of  the  problem. 
This  is  a  central  concept  in  the  object-oriented  approach;  consequentlj^,  the  first 
heuristic  is  the  most  important  from  a  pure  modeling  perspective  and  should  be  the 
first  consideration  in  determining  concurrency  in  a  particular  system.  The  remaining 
heuristics  are  important  from  a  practical  standpoint,  since  considerations  unrelated 
to  producing  a  model  of  the  problem-space  may  force  the  designer  to  implement 
concurrency;  for  example,  a  periodic  teisk,  or  a  computationally  intensive  task,  or 
a  shared  data  store  may  not  have  corresponding  objects  in  the  problem-space,  yet 
they  require  concurrency  implementation  nonetheless.  To  ensure  the  primacy  of  the 
model,  however,  the  first  heuristic  should  be  considered  first. 

6.3  Recommendations 

In  this  thesis  the  concurrency  heuristics  were  applied  to  the  ATC  simulation, 
for  which  concurrency  was  rather  easily  determined.  The  ATC  problem  was  a  self- 
contained  system  which  had  a  rather  simple  user  interface  and  no  external  objects 
other  than  the  keyboard  and  display.  Also  the  ATC  was  not  a  ‘hard’  real-time  system, 
i.e.,  missing  a  timing  constraint  (display  update)  did  not  constitute  a  system  failure. 
Another  characteristic  of  the  ATC  problem  as  implemented  in  this  thesis  was  that 
a  single-processor  system  Wcis  assumed. 

One  possible  area  for  further  exploration  is  to  see  if  the  heuristics  apply  as 
well  to  other  kinds  of  real-time  systems.  Do  they  work  as  well  for  more  complex 
problems,  ones  with  hard  real-time  requirements,  or  that  require  external  files  to  be 
maintained  in  real-time?  Systems  which  require  a  large  number  of  interrupt  handling 
routines  would  also  be  a  good  candidate. 

Another  area  for  further  research  is  in  applying  the  heuristics  to  distributed 
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real-time  systems.  One  of  the  assumptions  of  this  thesis  was  that,  even  in  a  dis¬ 
tributed  system,  there  may  be  more  than  one  process  executing  on  a  processor,  so 
the  heuristics  apply  at  the  processor  or  node  level;  the  network  or  system  level  was 
not  considered.  At  the  network  level,  issues  external  to  the  system  being  designed 
must  be  'Xnsidered,  such  as  the  processor  interconnection  network,  the  interproces¬ 
sor  message  passing  mechanism,  and  load  balancing  among  the  processors.  It  should 
be  determined  how  the  concurrency  heuristics  may  be  applied  to  these  issues,  or 
what  heuristics  must  be  added  to  the  set  to  cover  distributed  systems. 
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Appendix  A.  Air  Traffic  Control  Simulation  Object- Class 
Specifications  and  Ada  Specifications 

This  appendix  contains  the  object-class  specifications  for  the  Air  Traffic  Con¬ 
trol  simulation  introduced  in  chapter  four,  followed  by  the  Ada  package  specifications 
for  the  major  system  objects. 

A.l  Object-Class  Specifications 
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CLASS  SPECIFICATION 


Class  Name:  ATC 


Description:  This  is  the  main  object  of  the  simulation.  It  controls  the  interaction  of  the  other  objects. 


Static  Relationships 


Dynamic  Relationships 


Suffered  Operations 
Descriptive  Name 


Requited  Operations 
Name  Applied  to 


Selectors: 


^lectors: 


Constructors: 


GetJD 

Command 

IsJStatus 

Command 

Is.Termination 

Command 

U.COMMAND 

Command 

DispJ’reJdge 

Console 

Disp_MapJtem 

Console 

Disp.Titrte 

Console 

DispJnput 

Console 

DispJloger 

Console 

GetJnput 

Console 

Creste.Cmd 

Command 

Name 

Raised  by 

Fuiceptions 

QA 

TimeJixpited 

ATC 

Invalid.Cmd 

Command 

Invalid_Acft 

Command 

Initial; 

IFuel  J!xhaustcd  Airspace 

Conhict^tror 

Airspace 

BdatyJEttor 

Airspace 

Figure  A.l.  ATC  Object-Class  Specification 
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CLASS  SPECIFICATION 


Class  Name:  Airspace 


Description;  Represents  the  airspace  abstraction. 


Static  Relationships 


SufTered  Operations 
Descriptive  Name 

Selectors;  IsJDone 

GetJ.andmarkXocatian 


Constructors; 


Requited  Operations 
Name  Applied  to 


electors;  GetJD  Command 

IsJStatus  Command 

Is.Tetmination  Command 

Is.COMMAND  Command 

GetXocation  Landntatk 

GetJD  Aittiafl  • 

GetJSouice  Aircaft 

GetJ>estinatioa  Aircnfl 

Get.ETA  Aircraft 

Get.Class  Aircraft 

GetJleading  Aircralt 

GetJuel  Aircraft 

GetJ’oeition  Aircraft 

Get_Altitude  Aircraft 

onstructors;  SetJx>catioD  landmark 

SetJ,andmatk  landmark 

SetJD  Aircraft 


Figure  A. 2.  Airspace  Object-Class  Specification 
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CLASS  SPECIFICATION 


jClaM  Name:  Airspace 

(Continued)  | 

9 

Description:  Represents  the  airspace  abstraction. 

Suffered  Operations 

Required  Operations 

Descriptive  Name 

Name 

Applied  to  1 

Constructors; 

Constructors;  SetJ'lightJ’Ian 

Aircraft 

Set.Class 

Aircraft 

SetJIeading 

Aircraft 

Set^Ititude 

Aircraft 

Sct-FucI 

Aircraft 

SetJ’oeition 

Aircraft 

Take-Off 

Airaaft 

Hold-at-Navaid 

Aircraft 

Clr-for-Apprch 

Aircraft 

Clr-forXdg 

Aircraft 

Continue-Straight  Aircraft 

Update-Poaition 

Aircraft 

Uerators;  Update^irspace 

Iterators: 

Exceptions 

Name  Raised  by 

QA 

Fuel  Jlxhausted  Aircraft 

Conflict^rror  Airspace 

Initial; 

BdaryJItrot  Airspace 

Figura  A. 3.  Airspace  Object-Class  Specification(continued) 
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lOass  Name:  Landmark 


CLASS  SPECIFICATION 


Description:  This  class  represents  a  landmark  and  its  position  within  the  airspace.  A  landmark  can  be  one  of  three 
types:  a  navaid,  an  airport,  or  an  entry /exit  fix.  Each  of  these  has  two  or  more  possible  values:  2  navaids,  2  airports, 
10  entry/exit  fixes. 


Static  Relationships 


Suffered  Operations 
Descriptive  Name 

Selectors:  GetJLocation 

Constructors:  SetJ.ocation 
SetJLandmark 


Dynamic  Relationships 


Required  Operations 
Name  Applied  to 


(Selectors; 

jCoQstr'jctors: 


Name 


Raised  by 


Exceptions 


QA 


unitial: 


Figure  A. 4.  Landmark  Object-Class  Specification 
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CLASS  SPECIFICATION 

[Class  Name:  Fix 


Description:  This  class  represents  an  entry/exit  fix  which  is  a  kind  of  landmark. 


Static  Relationships 


Suffered  Operations 
Descriptive  Name 


Selectors:  GetJxication 

Constructors:  SetJ^ocation 
SetJLandmark 


Dynamic  Relationships 


Required  Operations 
Name  Applied  to 


Selectors: 

Constructors: 


Name  Raised  by 


Exceptions 


QA 


Unitial: 


Figure  A. 5.  Fix  Object-Class  Specification 
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Class  Name:  Navaid 


CLASS  SPECIFICATION 


Description;  This  class  represents  a  navigational  beacon  which  is  a  kind  of  landmark. 


Static  Relationships 


Dynamic  Relationships 


SufTered  Operations 
Descriptive  Name 

Selectors;  GetJx>cation 


Constructors;  SetJ.ocation 


Selectors: 

Constructors; 


Required  Operations 
Name  Applied  to 


SetJ^andmark 


Name  Raised  by 


Exceptions 


QA 

Initial: 


Figure  A. 6.  Navaid  Object-Class  Specification 
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_ CLASS  SPECIFICATION 

Class  Name:  Airport 


Description:  This  class  represents  an  airport  which  is  a  kind  of  landmark. 


Static  Relationships 


Dynamic  Relationships 


Selectors: 


Suffered  Operations 
Descriptive  Name 

GetXocation 


Required  Operations 
Name  Applied  to 


Constructors:  SetJx>caiioo 
SetJ,andmatk 


Selectors: 

Constructors: 


Name 


Raised  by 


Exceptions 


QA 


bnitial: 


Figure  A. 7.  Airport  Object-Class  Specification 
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CLASS  SPECIFICATION 


Class  Name:  Airspace.Location 

Description:  Represents  the  location  of  an  object  in  the  airspace. 

Static  Relationships 

Dynamic  Relationships 

Airspace.Location  record 

Suffered  Operations 

Descriptive  Name 

Selectors: 

Constructors: 

Iterators: 

Required  Operations 

Name  Applied  to 

Selectors: 

Constructors: 

Iterators: 

Exceptions 

Name  Raised  by 

mnni 

Figure  A.8.  AirspaceXocation  Object-Class  Specification 
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CLASS  SPECIFICATION 


Class  Name:  Aitctafl 


Description:  Represents  the  aircraft  abstraction. 


Static  Relationships 


Class 


Suffered  Operations 
Descriptive  Name 


Selectors:  GetJD 

GelJSouree 

GetJ>estin8tion 

GetJTTA 

Get.Class 

GetJIeading 

GetJ\iel 

GetJPosition 

Get^ltitude 

Constructors;  SetJD 

SetJ'lightJ’lan 

Set.CIass 


Reouired  Operations 

Name  Applied  to 

Selectors;  GetXocation 

Alter  aft  J’oeition 

Get^ltitude 

Aircraft  J’osition 

GetJIeading 

Aircraft  J’osition 

GetJSource 

FlightJ>lan 

GetJ)estination 

FlightJ>lan 

Gel^ta 

FlightJ’lao 

Constniclors: 
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CLASS  SPECIFICATION 

Class  Name:  Aircraft 

(Continued) 

f 

Description:  Represents  the  aircraft  abstraction. 

Suffered  Operations 

Descriptive  Name 

Required  Operations 

Name  Applied  to 

Constructors:  Sct.FIcading 

Constructors:  Set-Location 

AircraftJosition 

Set^ltitude 

Set-IIeading 

AircraRJosition 

SetJ\iel 

SetuMtitude 

AircraRJosition 

SetJosition 

Set.Flight.Plan 

FlightJPlan 

Take.Off 

Hold.atJ^avaid 

Clear  Jorj\pproach 

ClearJorXanding 

ContinueJStraight 

Update-Position 

Exceptions 

Name  Raised  by 

mm 

Fuel-Bxhausted  Aircraft 

Figure  A. 10.  Aircraft  Object-Class  Specification(continued) 
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CLASS  SPECIFICATION 


Class  Name:  AircraftJPosition 


Description:  Represents  the  position  of  an  aircraft  within  the  airspace. 


Static  Relationships 


Suffered  Operations 
Descriptive  Name 


Required  Operations 
N.ame  Applied  to 


Selectors:  GetJxication 


lectors: 


Get^ltitude 


GetJleading 


Constructors:  SetXocstion 


.nstruetors: 


SetJIeading 

Set_Altitude 
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_ CLASS  SPECIFICATION 

Class  Name:  Flight  J’lan 


Description:  Represents  the  flight  plan  of  a  particular  aircraft. 


Static  Relationships 


Dynamic  Relationships 


Suffered  Operations 
Descriptive  Name 


Required  Operations 
Name  Applied  to 


Selectors:  GetjSource 

GetJDestination 
GetJita 

Constructors:  Set  J'lightJ’lan 


jSelectors: 


iConstructors: 


Name 


Raised  by 


Exceptions 


QA 


Qnitial: 


Figure  A. 12.  Flight-Plan  Object-Class  Specification 
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CLASS  SPECIFICATION 


Class  Name:  Altitude 

D(.“scription:  Represents  the  altitude  of  an  aircraft. 

Static  Relationships 

Dynamic  Relationships 

Altitude  — —  integer 

Suffered  Operations 

Descripti\-j  Name 

Selectors; 

Constructors: 

Iterators: 

Required  Operations 

Name  Applied  to 

Selectors: 

Constructors: 

Iterators: 

Exceptions 

Name  Raised  by 

Figure  A. 14.  Altitude  Object-Class  Specification 
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CLASS  SPECIFICATION 


Class  Name:  Heading 


Description:  Represents  the  heading  of  an  aircraft. 


Heading 


Static  Relationships 

AKO 


-1 


enumeration  type 


Suffered  Operations 
Descriptive  Name 


Selectors: 

Constructors: 

Iterators: 


Dynamic  Relationships 


Required  Operations 
Name  Applied  to 


Selectors: 

Constructors: 

Iterators; 


Name 


Raised  by 


Exceptions 


QA 


[Initial: 


Figure  A. 15.  Heading  Object-Class  Specification 
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CLASS  SPECIFICATION 


Class  Name:  ETA 

Description:  Repiesents  the  estimated  time  which  an  aircraft  will  appear  on  the  display. 

Static  Relationships 

Dynamic  Relationships 

ETA  —  integer 

Suffered  Operations 

Descriptive  Name 

Selectors: 

Constructors: 

Iterators: 

Required  Operations 

Name  Applied  to 

Selectors: 

Constructors: 

Iterators: 

Exceptions 

Name  Raised  by 

QA 

Initial: 

Figure  A. 16.  ETA  Object-Class  Specification 
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CLASS  SPECIFICATION 

Class  Name:  Source 

Description:  Represents  the  source  of  an  aircrafts  flight  plan. 

Static  Relationships 

Dynamic  Relationships 

AKO  » 

Source  - —  enumeration  type 

Suffered  Operations 

Descriptive  Name 

Selectors: 

Constructors: 

Iterators: 

Required  Operations 

Name  Applied  to 

Selectors: 

Constructors: 

Iterators: 

Exceptions  QA 

Name  Raised  by 

Initial: 

Figure  A. 17.  Source  Object-Class  Specification 
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_ CLASS  SPECIFICATION 

Class  Name:  Destination 


Description:  Represents  the  destination  of  an  aircrafts  flight  plan. 


Static  Relationships 


Destination 


AKO 


enumeration  type 


Selectors: 


Suffered  Operations 
Descriptive  Name 


^lectors: 


Dynamic  Relationships 


Required  Operations 
Name  Applied  to 


Constructors: 


instructors: 


Iterators: 


Name  Raised  by 


[iterators; 


Exceptions 


QA 

Initial: 


Figure  A. 18.  Destination  Object-Class  Specification 
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CLASS  SPECIFICATION 

Class  Name:  AircraftJD 

Description:  Represents  the  tail  number  on  an  aircraft. 

Static  Relationships 

Dynamic  Relationships 

AircraftJD  character 

• 

Suffered  Operations 

Descriptive  Name 

Selectors: 

Constructors: 

Iterators: 

_ 

Requited  Operations 

Name  Applied  to 

Selectors: 

Constructors: 

Iterators: 

Exceptions  QA 

Name  ■  Raised  by 

Initial: 

Figure  A. 19.  AircraftJD  Object-Class  Specification 
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CLASS  SPECIFICATION 


Class  Name:  Command 


Description:  Provides  the  command  abstraction  for  the  ATC  simulation. 


Static  Relationships 


Suffered  Operations 

Descriptive  Name 

Required  Operations 

Name  Applied  to 

Selectors:  GetJD 

Selectors: 

IsJStatus 

Is.Termination 

Is.COMMAND 

Constructors:  Create.Command 

Constructors: 

Exceptions 

Name  Raised  by 

QA 

Invalid.Cmd  Command 

Initial: 

Invalid^ircraR  Command 

Figure  A.20.  Command  Object-Class  Specification 
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CLASS  SPECIFICATION 

[class  Name:  Console  _ 


Description:  This  object  provides  the  I/O  abstraction  for  the  ATC  simulation. 


Static  Relationships 


Dynamic  Relationships 


Suffered  Operations 
Descriptive  Name 


Constructors:  DispJ’rev.Msg 
Disp^lapJtcm 
Disp.Time 
DispJnput 
DispJtoger 
GetJnput 


Reouired  Operations 
Name  Applied  to 

jConstructors:  Disp.Prev^fsg  Display 
DispJdapJtem  Display 
Disp.Time  Display 
DispJnput  Display 
DispJloger  Display 
GetJnput  Keyboard 


Name 


Raised  by 


Exceptions 


QA 


hnitial: 


Figure  A. 21.  Console  Object-Class  Specification 
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CLASS  SPECIFICATION 

|Clas3  Name:  Keyboard 


Description:  Provides  the  interface  to  the  physical  keyboard. 


Static  Relationships 


Sufleced  Operations 
Descriptive  Name 


Constructors:  GetJnput 


instructors: 


Name 


Raised  by 


Exceptions 


I 


Dynamic  Relationships 


Required  Operations 
Name  Applied  to 


QA 

Initial; 


Figure  r\.22.  Keyboard  Object-Class  Specification 
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Class  Name:  Display 


CLASS  SPECIFICATION 


Dcsctiption:  Provides  the  output  for  the  simulation. 


Static  Relationships 


Suffered  Operations 
Descriptive  Name 


Constructors;  DispJ’tev^fsg 
,  Disp^fapJtem 

Disp.Time 
DiapJnput 
DispJloger 


Required  Operations 
Name  Applied  to 

nslructora:  DispJ’rev^sg  Pteview^rea 

Disp.A(apJtem  Map.Atem 

Disp.Time  Time.Area 

DispJnput  Input.Area 

DispJRoger  Re*pon8e.Area 


Figure  A. 23.  Display  Object-Class  Specification 


CLASS  SPECIFICATION  _ I 

[class  Name:  Preview^rea  ( 


Description:  Represents  the  area  of  the  display  where  the  preview  messages  are  shown. 


Static  Relationships 


Dynamic  Relationships 


Suffered  Operations 
Descriptive  Name 


Required  Operations 
Name  Applied  to 


Constructors:  DLspJtev^fsg 


Name  Raised  by 


IConstruetors:  DispJ’rev..Msg 


Exceptions 


Screen 


QA 


hnitiai: 


Figure  A. 24.  Preview _Area  Object-Class  Specification 
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CLASS  SPECIFICATION 

Class  Name:  Map-Area 

Description:  Represents  the  area  of  the  display  where  the  map  of  the  control  space  is  displayed. 

Static  Relationships 

Dynamic  Relationships 

Map-Area 

bu4)trta 

Screen 

BIh 

Suffered  Operations 

Descriptive  Name 

Constructors:  Disp^fapJtem 

Required  Operations 

Name  Applied  to 

Constructors:  Disp.AlapJtem  Screen 

Exceptions 

Name  Raised  by 

QA 

Initial: 

Figure  A.25.  Map„‘\.rea  Object-Class  Specification 
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_ CLASS  SPECIFICATION 

Class  Name:  Time_Area 


Description:  Represents  the  area  of  the  display  where  the  time  remaining  is  displayed. 


Static  Relationships 


Suffered  Operations 
Descriptive  Name 


Constructors:  Disp.Time 


Dynamic  Relationships 


Required  Operations 
Name  Applied  to 

jConstructors:  Disp.Time  Screen 


Name 


R.aised  by 


£  ;e<  •'tions 


QA 


hnitial: 


Figure  A.26.  Ti.TieJ^rea  Object-Class  Specification 


_ _ CLASS  SPECIFICATION 

Class  Name:  Input-Area 


Description;  Represents  the  area  of  the  display  where  the  input  is  echoed. 


Static  Relationships 


Dynamic  Relationships 


Input-Area 

■ 

B 

— 1  Screen 

Suffered  Operations 
Descriptive  Name 


Required  Operations 
Name  Applied  to 


Constructors;  DispJnput 


Name  Raised  by 


IConstructors;  DispJnput 


Exceptions 


Screen 


QA 

Initial: 


Figure  A. 27.  Input-Area  Object-Class  Specification 


A-28 


_ CLASS  SPECIFICATION 

Class  Name:  Response-Area 


pcscriplion:  Represents  the  area  of  the  display  where  the  system  response  is  displayed. 


Static  Relationships 


Dynamic  Relationships 


Suffered  Operations 
Descriptive  Name 


ICoDstructors;  DispJloger 


Requited  Operations 
Name  Applied  to 

{Constructors:  DispJlesponse  Screen 


Name 


Raised  by 


Exceptions 


QA 


■Initial: 


Figure  A. 28.  Response-Area  Object-Class  Specification 
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CLASS  SPECIFICATION 

[Class  Name:  Screen 


Description:  Provides  the  interface  to  the  physical  screen. 


Static  Relationships 


Dynamic  Relationships 


Suffered  Operations 
Desaiptive  Name 


Required  Operations 
Name  Applied  to 


Constructors:  DispJrevJdsg 


(Constructors: 


Disp.MapJtem 

DispJIime 

DispJnput 

DispJtesponse 


Name  Raised  by 


Exceptions 


QA 


Initial: 


Figure  A. 29,  Screen  Object-Class  Specification 
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CLASS  SPECIFICATION 


Cla£s  Name;  Simulation.Time 

Description;  Represents  the  time  remaining  in  the  simulation. 

Static  Relationships 

Dynamic  Relationships 

AKO 

Simulation.Time -  integer 

Suffered  Operations 

Descriptive  Name 

Selectors; 

Constructors; 

Iterators; 

Required  Operations 

Name  Applied  to 

Selectors; 

Constructors; 

Iterators; 

Exceptions 

Name-  Raised  by 

iimi 

Figure  A. 30.  Simulation-Time  Object-Class  Specification 
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CLASS  SPECIFICATION 


Class  Name:  MapJtem 

Description:  Represents  an  item  to  be  placed  in  the  map  display. 

Static  Relationships 

Dynamic  Relationships 

MapJtem  ai^  record 

Suffered  Operatisns 

Descrip  tive^Name 

Selectors: 

Constructors: 

Iterators: 

Required  Operations 

Name  Applied  to 

Selectors: 

Constructors: 

Iterators; 

Exceptions 

Name  Raised  by 

Figure  A, 31.  MapJtem  Object-Class  Specification 
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CLASS  SPEGIEICATION 

Class  Name:  Preview.Me3sage.Count 

Description;  Represents  the  number  of  the  current  preview  message. 

Static  Relationships 

Dynamic  Relationships 

Preview.Message.Count  integer 

Suffered  Operations 

Descriptive  Name 

Selectors: 

Constructors: 

Iterators: 

Required  Operations 

Name  Applied  to 

Selectors: 

Constructors: 

Iterators: 

Exceptions 

Name  Raised  by 

■mmi 

Figure  A. 32.  Preview_Message_Count  Object-Glass  Specification 
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CLASS  SPECIFICATION 

Class  Name:  Pteview.Message 

Description:  Represents  the  string  into  which  the  preview  message  is  placed. 

Static  Relationships 

Dynamic  Relationships 

Preview.Message  string 

Suffered  Operations 

Descriptive  Name 

Selectors: 

Constructors: 

Iterators: 

Required  Operations 

Name  Applied  to 

Selectors: 

Constructors: 

Iterators: 

Exceptions 

Name  Raised  by 

|K9|| 

Figure  A. 33.  Preview_Message  Object-Class  Specification 


A. 2  Ada  Specifications 

Following  are  the  Ada  package  and  subprogram  specifications  for  the  ATC 
problem.  Only  the  major  objects  are  included. 

A.2.0.1  ATC  Object 


Bith  Calendar; 
with  Text_I0; 
use  Text.IO; 
with  Conunand.PKG; 
use  Coimnand.PKG ; 

Bith  Console.PKG; 

Bith  Classes_PKG; 
use  Classes.PKG; 

»'t;i  airspace.P.lG; 

Bith  Aircraft_Attributes_PKG; 
procedure  ATC  is 

—***« t******* t ********************* tt**ee*e*»*****e**e**e*t***t*t*te- 


--  CLASS: 
—  REPRESEHTATIOa: 
T-  USED  BY: 

USES: 


OPERATIOBS: 


ATC 

none 

none 

Command,  Classes,  Airspace,  Console, 
Aircraft.Attributes,  Calenda.  ,  Text.IO 
none 


—  PURPOSE:  This  object  represents  the  the  entire  air  traffic  contol 
r-  simulation. 

--******************************************************************* 


Simulation_Leugth:  Classes.PKG. Simulation_Time; 

This.Command:  Coiroand.PKG. Command; 

Conti oller.Input :  Classes.PKG .Tnput.String; 

Time.Expired : exception ; 

package  Time. 10  is  nev  intdger.ioCClasses.PKG.Simulation.Time); 
task  Update.Airspaco  is 

t-ulxy  SlailCS.imulalion.Lojiglh:  in  Classes.PKG. Simulation.Time); 
entry  Stop; 
end  Update. Airspace; 

use  Calender; 
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task  body  Update.Aixspace  is 
Timo.Lef  t :  Classos.PKG .  Sinulation.Tinie ; 

Minuto_Counter:  integer :=lj 
Tiae.Expired: exception; 

V  ext .Update : Calendar . Time ; 

Updat e.Int erval : durat ion : =1 5 . 0 ; 
begin 

accept  Start (Simulation.Length:  in  Classes.PKQ.Sinulation.Time)  do 
Time.Lef  t  :=Sijiralation_Length; 
end  Start; 

Console.PKG .  Display.Time  (Tijne_Lef  t )  ; 

Rext.Update ; =Calendar . clock ; 
loop 

Rext.Update :=Hext_Update  +  Update.Interval; 
delay  Rext.Update  -  Calendar. clock; 

—  retrieve  airspace  updates 

—  display  airspace  updates 
if  Minute.Counter=4  then 

Time.Lef t :=TiBe.LeftTl; 

Console.PKG . Display.Time (Time.Lef t) ; 
if  Time_Left=0  then 
raise  Time.Expired; 
end  if; 

Minute.Counter : “1 ; 
else 

Hinut i.Count  er : =Binut  oiCounter +l . 
end  if; 
select 

accept  Stop; 
exit; 
else 
null; 

end  select ; 
end  loop; 

end  Update.Airspace; 
begin 

putC'Enter  the  simulation  length:  "); 

Time.IO.get(Simulation.Length) ; 

—  Dran.Initial.Map; 

Update.Airspace. Start (Siaulation.Length) ; 

delay  1.0; 

loop 
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Controllor_Input : =Console_PKG .get_input ; 

Console_PKG . Display.Input (Controller.Input) ; 

If  Coin)aaMd_PKG.Is_Terniination.Raqucst(Controller_Input)  then 
Console.PKG .Display.Input ("Terminating  simulation . ; 

—  Terminato.Sinulation; 

Update. Airspace . Stop ; 
exit; 
end  if; 
begin 

Thi8_Conmand:=  CoBmand.PKG.Create.Couimand(Controller.Input); 
exception 

when  Invalid.Command  => 

Console.PAG. Display.Input ("Invalid  command.")  ; 
when  Invalid.Aircraft  => 

Console.PKG . Display.Input ("Invalid  aircraft . “) ; 
when  others  => 

Console.PKG. Display.Input ("Something  else  went  wrong.") ; 

end; 

if  not  Command.PKG.Is.Statusdhis.Command)  then 
Console.PKG . Display. Roger ; 

"  Execute  Command 
else 

"  Gat  Status 
"  Display  Status 
null; 
end  if; 
delay  1.0; 
end  loop; 
exception 

when  Time.Expirod=> 
p’lt.lineC'You  ran  out  of  time!!!!!"); 
when  others  => 

put.line ("Something  bad  went  wrong.") ; 
end  ATC; 

with  Aircraft.PKG; 

with  Aircraft.Attributes.PKG; 

with  Command; 

with  Landmark.PKG ; 

with  Classes.PKG; 

package  Airspace.PKG  is 

CLASS:  Airspace 
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—  REPRESESTATIOI: 

USED  BY: 
USES: 
OPERATIUHS: 


none 

ATC 

CoBmand,  Landmark,  Classes,  Aircraft  Attributes 

Initialize.Aicspace  -  sets  the  location  of  all 
landmark'!  in  the  airspace  and 
passes  it  back  to  ATC  for 
display 

Update.Airspace  -  gets  the  position  updates 
of  the  aircraft,  chocks  for 
errors,  and  passes  the  updates 
back  to  ATC 

Execute.Command  -  performs  the  specified  command 
on  the  specified  aircraft 

Is.Done  -  returns  true  if  26  aircraft  )  .»o 

been  dispositioned 

Get.Landmark.Locatiott  -  returns  the  location  of  the 
specified  landmark, 
based  on  the  heading,  speed,  etc. 


”  PURPOSE:  This  clans  represents  the  airspace. 

— eeeeeeeeeeeeteeeeeet  ****eeeee*e**e*e4i»te*e**<i*t*«*e******e***e***** 


package  Update_Record_List  is  neu  ???????(Update_Rocord_PKG.Update_Racord) ; 
procedure  Initialize. Airspace  (Dpdate.Listr  out  Update.RecordiList) ; 
procedure  Update.Airspace  (Update.List :  out  Update.RocoTd_List) ; 
procedure  Exccute_Conmand  (This_Command:  in  Ccminand.PKG. Command; 

This.Aircraft : Aircraft. Attributes.PKG.Aircraft.ID) 
function  Is.Done  return  Boolean; 

function  Get.Landmark.Location(This.Landmark:  in  Landmark.PKGTLwdmark) 

return  Classes.PKG . Airspace.Position; 

end  Airspace.PKQ; 


Bith  Aircraft.Position.PEG; 
with  Flight. Plan.PKG; 
with  Aircraft.Attributes.PKG; 
package  Aircraft.PKG  is 

— ****************e****e*e*e**4  t*e«*******«**********i*»******t*_***** 


CLASS 

—  REPRESESTATIOI 
USED  BY 
USES 
OP  :ratio«s 


Aircraft 

record 

Airspace 

Aircraft.AttriUiitds,  Flight.Plan,  Aircraft.Position 
Get.ID  -  returns  the:  ID  of  the  aircraft 

Get. Source  -  returns  tho  source  of  tho 
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aircraft 


Get.Dastination 

Gct.ETA 

Got.Clasc 

Got.noading 

Oot.Fual 

Got_Position  - 

Gat_Altitud«  - 


-  roturns  the  destination  of  the 
aircraft 

returns  the  ETA. of  the  aircraft, 
the  tiae  the  aircraft  nill  appear 
on  the  display. 

returns  the  class  of  aircraft, 
uhether  it  is  a  jet  r  prop, 
returns  the  heading  of  the  aircraft 
returns  the  fuel  level  of  the 
aircraft 

returns  the  3  dimensional  position 
of  tho  aircr.aft 

returns  the  altitude  of  the  aircraft 


Set.ID  -  assigns  an  ID  to  the  aircraft 

Set_Flight_Plan  -  assigns  a  flight  plan  to  the 
aircraft 

Set.Class  -  assigns  a  class  to  the  aircraft 
Set.Heading  -  assigns  a  heading  to  the  aircraft 
Set. Altitude  -  assigns  an  altitude  to  the  aircraft 
Set.Fuel  -  assigns  a  fuel-level  to  the  aircraft 
Set.Position  -  assigns  a  position  to  the  aircraft 
Take. Off  -  s»ts  the  Take.Off  flag  to  true 

lIold.at.Baraid-  sets  the  Bold.at.Bavaid  flag  to  true 
Clear.for.Approach  -  sets  the  Clcar.f or.Approach f lag 
to  true 

Clear.for.Landing  -  sets  the  Clear.for_Landing  flag 
to  true 

Continue.Straight  -  does  nothing 

Update.Position  -  sets  the  nes;position  of  tho  aircraft 
based  on  the  heading,  speed,  otc. 


—  PURPOSE:  This  class  represents  an  aircraft  in  the  airspace 

--*e*v**e*«*****4i********e****4.*********«*********e**********ee«**ee* 


type  Aircraft  is  private; 

function  Get.ID  (This.Pian:  in  Aircraft) 

return  Aircraft.Attributes.PKG.Aircraft.ID; 
function  Cot.Sourco  (This.Pian:  in  Aircraft) 

return  Aircraf t.Attributes.PKG . Source ; 
function  Get.Destination  (This.Pl^:  in  Aircraft) 

return  Aircraft.Attributes.PKG. Destination; 
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function  Get.ETA  (This.Plan:  in  Aircraft) 

return  Aircraf t_Attributes_PKG . ETA.Type ; 
function  Get_Class  (This.Plan:  in  Aircraft) 

return  Aircraf t.Attributes.PKG . Class ; 
function  Get.Hoading  (This.Plan:  in  Aircraft) 

return  Aircraft.Attributes.PXG.Beading.Type; 
function  Get.Fuel  (This.Plan:  in  Aircraft) 

return  Aircraf t.Attributes.PKG . Fuel ; 
function  Get. Position  (This.Plan:  in  Aircraft) 

return  Aircraf t.Position.PKG . Aircraf t. Position ; 
function  Get.Altitude  (This.Plzin:  in  Aircraft) 

return  Aircraf t.Attributes.PKG. Alt itude.Type; 
procedure  Set. ID  (This.ID:  in  Aircraf t.Attributes.PKG. Aircraft. ID; 

This.Plane:  out  Aircraft); 

procedure  Set.Flight.Plan  (This.Src:  in  Aircraf t.Attributes.PKG. Source; 

This.DST:  in  Aircraf t.Attributes.PKG. Destination; 
This.ETA:  in  Aircraf t.Attributes.PKG. ETA.Type; 
This.Plane  :  out  Aircraft); 

procedure'Set.Class  (This.Class:  in  Aircraf t.;Attributes.PKG. Class; 

This.Plane  :  out  Aircraft) ; 

procedure  Set_Heading-(This.Beading:  in  Aircraft.Attributes.PKG.Beading.Type; 

This.Plane  ;  out  Aircraft) ; 

procedure  Set.Altitudo  (This. Altitude:  in  Aircraft_Attributes.PKG.Altitude.Type; 

This.Plane  :  out  Aircraft) ; 

procedure  Set.Fuel  (This.Fuel:  in  Aircraf t.Attributes.PKG. Fuel; 

This.Plane  :  out  Aircraft) ; 

procednre-Set.Position  (This.Position:  in  Aircraft.Position.PKG .Aircraft.Position 

This.Plane  :  out  Aircraft); 
procedure  Take.Off  (This.Position:  out  Aircraft); 
procedure  Bold.at.Havaid  (This.Position:  out  Aircraft) ; 
procedure  Clear.for.Approach  (This.Position:  out  Aircraft); 
proceduro:Clear_f or^Landing  (This.Position:  out  Aircraft) ; 
procedure  Continue.Straight  (This.Position:  out  Aircraft); 
procedure  Update.Position  (This.Position:  out  Aircraft); 
private 

type  Aircraft  is 
record 

ID :  Aircraf t.Attributes.PKG . Aircraf t.ID ; 

Active:  Boolean :=false; 

Flight.Plan:  Flight.Plan.PKG.Flight.Plan; 

Class :  Air craf t.Attributes.PKG . Class ; 

Fuel.Level :  Aircraf t.Attributes.PKG . Fuel; 

Position:  Aircraf t.Position.PKG. Aircraft.Position; 
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Approach:  6oolean:=false; 
Landing  :  Boolean:=false; 
Hold  :  Boolean :=f also; 
end  record; 
end  Aircraft_PKG; 


A.2.0.S  Console  Object 


-***************************************************'**************** 

OBJECT:  Console 

-  RF<’RESEITATIOI :  Subobjocts  -  display,  keyboard 

USED  BY:  ATC 

-  USES:  Display _PKG,  Keyboard.PKG,  Classes.PXG 

-  OPERATIOSS:  Display _PrevieR_Message  -  displays  a  previen 

-  message  in  the  previen  area 
Display.Hap.Item  -  displays  a  single  map  item 

-  in  the  map  area 

~  Display.Time  -  displays  the  time  remaining  in 

the  simulation  in  the  time  area 
~  Display.Input  -  echos  the  input  to  the  screen 

-  Get.Input  -  gets  input  from  the  keyboard 
Display.Rogor  -  displays  a  ‘‘ROGER"  message  in 

'  the  response  area 

-  Clean.Up  -  kills  all  tasks  at  the  termination 

“  of  the  simulation 

-  PURPOSE:  Provides  the  I/O  to  the  ATC  simulation. 


— e****************************************************************** 

nith  Classes.PKG; 
package  Console_PKG  is 
procedure  Display.Previev.Hessage 

(Hext.Hessage:  inClasses.PKG.PrevieR.Hessage; 

Hsg.Num:  in  Classes.PKG. Previev.Hessage.Count) ; 
procedure  Display.Nap.ItemCThis.Item:  in  Classes.PKG. Hap.Item) ; 
procedure  Display .Timedew.Time;  in  Classes.PKG. Simulation.Time); 
procedure  Display.InputCThis.Input:  in. String); 
function  Get.Input  return  String; 
procedure  Display .Roger; 
procedure  Cleah.Up; 
end  Console.PKG ; 


- ********************************************»»0****»*^***tt*tni**** 

—  OBJECT :  Keyboard 

Subobjects  -  none 
Console 


—  REPr E5ESTATI0H: 

USED  BY: 
USES: 
OPERATIOHS: 


Get.Input  -  gets  a  string  from  the  use 
Clean.Up  -  kills  the  task  at  the  termination 
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of  the  simulation 


PURPOSE;  Provides  the  input  from  the  physical  keyboard. 


— **********e*e****************ee***e***********e******«****v*v*****e 

package  Keyboard.PXG  is 
function  Get_Input  return  String; 
procedure  Clean_Up; 
end  Keyboard.PKG; 


with  Classes_PKG; 
package  Display.PKG  is 

— *****•**********************•*«'********«*********•*****•******••*** 

OBJECT:  Display 

—  REPRESEITATIOK :  Subobjects  -  areas:  preview,  map,  response, 

—  input,  time 


USED  BY:  Console 

USES :  Pf eview.Area.PKG ,  Response. Area.PXG, 

Map.Area.PKG,  Time.Area.PKG,  Input.Area.PKG, 
Classes.PKG,  Screen.PKG 

OPERATIOIS:  Display _Preview.^Hessage  -  displays  a  preview 

message  in  the  preview  area 
Display.Map.Item  -  displays  a  single  map  item 
in  the:  map  area 

Display.Time  -  displays  the  time  remaining  in 
the  simulation  in  the  time  area 
Display.Input  -  echos  the  input  to  the  screen 
Get.Input  -  gets  input  from  the  keyboard 
Display.Roger  -  displays  a  "ROGER"  message  in 
the  responte  area 

Clean.Up  -  cleans  up  the  screen.  lOTICE;  This 
operation  directly  manipulates  the 
screen  object,  which  is  not  a 
component  object  of  the  display,  but 
is  a  component  of  display’s  component 
objects.  This  is  done  to  prevent  the 
the  invention  of  a  component  object 
of  display  called  ’Clean.Up.PKG’  or 
something  like  that, 
of  the  simulation 


PURPOSE:  Provides  the  output  for  the  ATC  simulation. 
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— **************t*****************^******************t*^*****»******* 


procedure  Display _Preview_Mossage 

(lext.Hessage:  in  Classes.PKG.Previeu.Hessage; 

Hsg.Ium:  in  Classes.PKC.Prcview.Hessage.Count) ; 
procedure  Display_Hap_Item(This_Item:  in  Classes.PXG.Hap.Item) ; 
procedure  Display _Tinie(leR_Tine:  in  Classes_PKG.Simulation_Tiiae) ; 
procedure  Display_Input(This_Input :  in  String); 
procedure  Display .Roger; 
procedure  Clean.Up; 
end  Display.PKG; 


nith  Classes.PKG; 
package  Previes.Area.PKG  is 

--******•******************************************************•***** 

—  OBJECT:  Preview. Area 

Sub-objects  -  screen 
Display 
Screen 

Display.Preview;Message  -  displays  a  preview 
message  in  the  preview  area 
Displays  a  preview  message  in  the  preview  area. 


—  REPRESEITATIOH : 

USED  BY: 
USES: 
OPERATIONS: 

PURPOSE: 


— ***ve4r'«»v*vvve*vve*v*v********v*v**e»4i4i*evvev**ee**vA**vvv**e*e*e** 

procedure  Display.Preview.Hessage 

(Next^Hessage:  in  Classes.PKG.Preview.Hessage; 
Hsg.Num:  in  Classes^PKG.Preview.Hessage.Count); 
end  Preview.Area_PKG; 


with  Screen.PKG; 

package  body  Preview.Area.PXG  is 
Area.x:constant  integer :=1; 

Area.y: constant  integer :=65; 
procedure  Display.Preview.Hessage 

(Next.Hessage:  in  Classes.PKG.Preview.Hessage; 
Hsg^Hum:  in  Classes.PKG.Preview.Hessage.Count)  is 

x,y:integer; 

begin 

—  Ibe  message  number  determines  which  line  the  preview  message 

—  is  printed  on.  This  prevents  messages  from  being  over- 

—  written  by  now  messages. 
x:=integer(Hsg_Bum) ; 

y: “Area.y; 

Screen.PKG .Display;Proview.Hessage(x,y, Next.Hessage) ; 
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ond  Display.PravieH.Messagfl; 
end  Proview_Area_PKG; 


package  ocreen.PXG  is 

— ******************************************************************* 

—  OBJECT:  Screen 

—  REPRESEHTATIOI :  Subobjocts  -  none 

—  USED  BY:  Display,  Preview.Area,  Hap.Area,  Time.Area, 

"  Input.Axea,  Response.Area 


USES: 
OPERATIOHS : 


Display.Previee.Hessage  -  displays  a  previee 
message  in  the  preview  area 
Display.Map.Item  -  displays  a  single  map  item 
in  the  map  area 

Display .Time  -  displays  the  time  remaining  in 
the  simulation  in  the  time  area 
Display.Input  -  echos  the  input  to  the  screen 
Display.Response  -  displays  a  message  in 
the  response  area 

Clean.Up  -  Kills  the  task  upon  termination 
of  the  simulation 


PURPOSE: 


Provides  the  interface  to  the  physical  screen. 


—e*vv*******e«****************v*v*v*v«v** *************************** 

procedure  Display_ProvieB_Message(x,y:in  integer; 

Next.Hessage:  in  String); 
procedure  Display _Map_Item(x,y:in  integer; 

Item:  in  character) ; 

procedure  Display _Time(x,y,HeH_Timo:  in  integer); 
procedure  Display_Input(x,y:  in  integer; 

This.Input:  in  String) ; 
procedure  Display_Response(x,y:  in  integer; 

This.Response : in  String); 

procedure  Clean.Up; 
end  Screen.PKG; 
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A.2.0.3  Command  Object 


with  Aircraft.Attributes.PKG; 
with  Classes.PKG; 
package  Conmand.PKG  is 

— ******************************************************************* 

—  CLASS ;  CoDmand 

—  REPRESEITATIOB:  Record 

USED  BY:  ATC 

USES:  KOBE 


OPERATIOHS: 


EXCEPTIOSS: 


Create.Cotnmand  -  builds  a  command  from  an 
input  string 

Get.lD  -  returns  the  ID  of  the  aircraft 

specified  in  the  passed  command. 

Is.Status  -  returns  true  if  the  passed 
command  is  a  status  request, 
false  otherwise . 

Is.Termination  -  returns  true  if  the  passed 
command  is  a  termination 
request,  false  otherwise. 

Is_<command>  -  returns  true  if  the  passed 
command  -  <command>,  false 
otherwise.  There  will  be 
one  of  these  for  each 
different  command. 

Invalid.Command-  this  exception  is  raised 
when  the  Direction  or 
Amount  parts  of  the  command 
are  illegal  values.  The 
exception  is  propagated  to 
the  ATC  object. 

Invalid.Aircraft-this  exception  is  raised 

when  an  invalid  Aircraft.ID 
is  detected.  The  exception 
is  propagated  to  the  ATC 
object . 


—  PURPOSE:  Represents  the  commands  used  in  the  ATC 

"  simulation. 

- **  t  *************  tt*****************:^******************************* 

type  Command  is  private; 

function  Create.Command  (This.String:  in  string) 

return  Command; 
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function  Get.ID  (Thls.Comsand;  in  Conaand) 

rotum  Aircraft_Attributos_PK6.Aircraft_ID; 
function  Is.Status  (This.Comaand;  in  Command)  return  boolean; 
function  Is.Termination.Roquest  (This_String:  in  Clas8eB_PKG,Input_String) 

return  boolean; 

function  Is_Clear_to_Land  (This.Command:  imCommand) 

return  boolean; 

function  ls_Turn_Loft_4S  (This.Command:  in  Command) 

return  boolean; 


Invalid.Command  :  exception; 

Invalid.Aircraft  :  exception; 
private 

—  Command  is  a  record  containing  the  folloning: 

—  1.  aircraft.ID  of  the  aircraft  being  commaitded 

—  2.  the  direction  character  vhich  determines  which 
“  direction  the  aircraft  should  go. 

L  -  left 
”  R  -  right 

”  A  -  ascend/descend 

"  3.  the  amount  character  which  specifies  how  far  the 
the  aircraft  should  turn/ascend/descend 

—  0  -  clear  to  land, -hold  at  navaid,  continue 

—  1  -  1000>/45  degrees 

—  2  -  2000 ’/90  degrees 

3  -  3000'/13S  degrees 

—  4  -  4000’/180  degrees 

—  5  -  SOOO’/clear  for  approach 

—  4.  a  boolean  whichiflags  the  command  as  a  status  request  or 
"  a  directive  command 

type  Command 
is  record 

Aircraft.ID  :  Aircraft.Attributes.PKG. Aircraft.ID; 
Direction  :  character; 

Amount  :  character; 

Is.a.Command  :  boolean :=true; 
end  record; 
end  Command.PKG; 

package  body  Command.PKG  is 

—  This  function  converts  a  string  into  a  command 
function  Create.ComnandCThis.String:  in  string) 

return  (Command  is 
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subtype  Upper.Case  is  character  range 
TeDp.Conmand:  Conmand; 

Ch  :  character; 

—  Function  to  convert  loser  case  characters  to  upper  case, 
function  upper  (Ch:  in  character)  return  character  is 
subtype  Lover.Case  is  character  range  ’a’..’z’; 
begin 

if  Ch  in  Loser.Case  then 

return  character’val(character’pos(Ch)-character’pos('  ’)); 
end  if; 
return  Ch; 
end  upper; 
begin 

—  Check  to  make  sure  the  aircraft  id  is  valid 
Ch:=upper(This_String(l)) ; 
if  not  (Ch  in  Upper.Caso)  then 
raise  Invalid.Aircraf t ; 
end  if; 

"  Check  for  status  message 
if  This.String ’length  =  1  then 

Temp.Command .  Is.a.Coinnand  ;=f  alse ; 

Temp_Coiinnand.Aircraft_ID  Ch; 

“■  Hust  be  a- conmand 
elsif  This.String’length  ==  3  then 
Temp.Conmand.Is.a.Conmand.  true; 

Temp.Command.Aircraft.ID  :=  Ch; 

—  Check  for  valid  direction  character 
—  If  valid,  assign  it 
Ch:=upper(This^String(2)) ; 
if  (Ch=’A’)  or  (Ch=>L’)  or  (Ch=’R’)  then 
Temp.Command . Direct ion: =Ch ; 
else 

raise  Invalid.Conmand; 
end  if; 

—  Check  for  valid  amount  character 
—  If  valid,  assign  it 
Ch:=This_String(3) ; 
if  Ch  in  ’O’.. ’5’  then 
Temp.Command . Amount : =Ch ; 
else 

raise  Invalid.Command; 
end  if; 
end  if; 
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xeturn  Tetap.Coisoiand; 
end  Crcate.Coraniind ; 

—  Tids  fttnetioR  returns  the  ID  of  the  aircraft  specified  in  the  cotmand 
function  Qet.IO  (I'his.Coomand :  in  Conmand) 

return  Aircraft_Attributes_PKQ.Aircraft_ID  is 

begin 

.return  This.Ccjsmijid  .AircraftJCD ; 
end  Oot_ID; 

—  This  function  returns  true  if  the  conmand  is  a  status  request, 

—  false lolhoruiao 

f!Uvcticn-l3_Status  (This.Conmand :  in  Conmand)  return  boolean  is 
begin 

if  not  This.Conmand. Is.a.Comnand  then 
return  true; 
else 

return  false; 
end  if; 

end  Is.Status; 

—  This^unction  returns-true  if  the  command  is  a  Clear_to.;Land 

—  command,  false  otherwise 

function  Is.Clear.to.Lahd  (This.Command:  in  Command) 

return  boolean  is 

begin 

if  (This.Conmand. Direction=’A>)  and  (This.Conmand. Amount=»0’)  then 
return  true; 
else 

return  false; 
end=  if ; 

end  Ic.Cloar_to.land; 

—  This  function  returns  ;true  if  the  command  is  a  turn  left  45 

—  degreos'conmand,  false  otherwise 

function  Is_Turn_left_45  (This.Command:  in  Command) 

return  boolean  is 

begin 

if  (This.Command. Direction=’L’)  and  (This.Conmand. Amount=>l»)  then 
return  true; 
else 

return  false; 
end  if; 
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<md  l8_Turn_I.o^t_4Sj 

—  This  function  returns  true  if  the  string  input  at  the  keyboard  is 

—  a  termination  request,  lulse  othoreise 

function  Is_Teraination_Requost  (This.String;  in  Clas8es_PK0.Inpat_String) 

return  boolean  is 

begin 

if  This.String  «=  "TER"  then 
return  true; 
else 

return  false; 
end  if; 

end  Is.Termination.Request ; 
end  Connand.PKG ; 
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Appendix  B.  Validation  Package 


This  chapter  contains  the  validation  package  used  to  validate  the  research 
presented  in  the  thesis.  Also  included  are  the  list  of  experts  consulted  and  the 
individual  responses  of  the  experts. 

B.l  The  Package 

The  validation  package  consists  of  a  discussion  of  the  concurrency  heuristics 
and  a  questionaire.  The  questionaire  is  reproduced  in  Figure  5.1.  The  remainder  of 
this  section  contains  the  textual  portion  of  the  package. 

B.Ll  Heuristics  for  determining  concurrency.  Following  are  four  heuristics 
which  designers  may  use  in  determining  concurrency  in  object-oriented  designs.  They 
are  based  on  the  heuristics  used  in  the  DARTS[Gomaa  1984],  LVM/OOD [Nielsen 
and  Shumate  1989],  ADARTS[Gomaa  1989a],  and  Entity-life  ModeUng[Sanden  1989] 
methods. 


BA.l.l  Problem-space  conci  'rency.  An  object  which  models  con¬ 
currency  in  the  problem  environment  should  be  implemented  as  a  task. 

Concurrency  in  the  problem-domain  can  be  determined  by  identifying  behav¬ 
ior  patterns,  or  sequences  of  events,  in  which  the  objects  participate.  The  objects 
themselves  may  represent  physical  entities  to  which  the  system  interfaces,  or  logical 
entities,  such  as  an  air  traffic  control  system. 

B.l. 1.2  Time  constraints.  An  object  whose  behavior  or  opera¬ 
tions  are  constrained  by  time  requirements  should  probably  be  a  task. 

These  may  be  periodic  constraints,  such  as  an  operation  which  must  be  per- 
formed^at  set  intervals,  or  responsive  constraints,  such  as  responding  to  an  Interrupt. 
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B.l.l.S  Computational  requirements.  An  object  whose  behavior  or 
operations  require  substantial  computational  resources  should  probably 
be  a  task. 

For  example,  in  a  satellite  romm  mication  system,  the  satellite  object  may  have 
an  operation  called  Calculate  Satellite  Coordinates.  To  do  this  in  real  time  requires 
the  integration  of  a  ninth-order  polynomial.  Depending  on  the  resources  available, 
this  could  be  quite  time  consuming  and  processor  intensive.  This  operation  should 
be  a  separate  task. 

B. 1.1.4  Solution-space  objects.  An  object  introduced  in  the  soft¬ 
ware  solution  to  protect  a  shared  data  store,  decouple  two  interacting 
tasks,  or  synchronize  the  behavior  of  two  or  more  objects  should  be  a 
task. 
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B.1.2  Application  of  the  Heuristics  to  the  ATC  Proble7n  The  heuristics  were 
applied  to  an  Air  Traffic  Control  (ATC)  simulation  .  This  section  contains  a  de¬ 
scription  of  the  problem  followed  by  a  discussion  of  the  concurrency  identified  via 
the  heuristics  and  concludes  with  a  discussion  of  the  overall  design  of  the  system. 
For  reference  the  Booch  diagrams  and  Ada  package  specifications  are  also  included. 

B. 1.2.1  ATC  Description 


Air  Traffic  Control  is  a  simulation  which  allows  the  user  to  play  the  part 
of  an  air  traffic  controller  in  charge  of  a  15x25  mile  area  from  ground 
level  to  9000  feet.  In  the  area  are  10  entry/exit  fixes,  2  airports  ,  and  2 
navaids.  During  the  simulation,  26  aircraft  will  become  active,  and  it  is 
the  responsibility  of  the  controller  to  safely  direct  these  aircraft  through 
the  airspace. 

The  controller  communicates  to  the  aircraft  via  the  scope,  issuing  com¬ 
mands  and  status  requests,  receiving  replies-and  reports,  and  noting  the 
position  of  the  aircraft  on  the  map  of  the  control  space.  The  controller 
issues  commands  to  change  heading  or  altitude,  to  hold  at  a  navaid,  or 
clear  for  approach  or  landing.  Each  aircraft  has  a  certain  amount  of 
fuel  left,  so  the  controller  must  see  to  it  that  the  aircraft  is  dispositioned 
prior  to  fuel  exhaustion.  Also,  the  minimum  separation  rules  must  be 
followed,  which  state  that  no  two  aircraft  may  pass  within  three  miles  of 
each  other  at  1000’  or  less  separation.  The  aircraft  must  enter  and/or 
exit  via  one  of  the  ten  fixes.  If  an  aircraft  attempts  to  exit  through  a 
non-exit  fix,  a  boundary  error  is  generated.  The  controller  may  request 
a  status  report  on  each  aircraft,  which  will  display  all  information  on  the 
aircraft,  including  fuel  level,  which  is  measured  in  minutes. 

The  aircraft  can  be  one  of  two  types,  a  jet  or  a  prop.  The  jets  travel  at 
4  miles  per  minute,  while  the  props  travel  at  2  miles  per  minute.  This 
means  the  screen  must  updated  every  15  seconds  for  a  jet’s  course  to  be 
followed  accross  the  screen. 

The  controller  dispositions  aircraft  by  giving  commands  which  enable  the 
aircraft  to  take  off,  land,  hold  at  a  navaid,  assume  a  landing  approach, 
turn,  or  change  altitude.  Take  off  is  accomplished  by  ordering  the  aircraft 
to  assume  a  certain  altitude;  there  is  no  ’take  off’  command  as  such.  Each 
of  the  airports  has  restrictions  on  heading  for  takeoff;  these  restrictions 
must  be  observed.  Turns  and  altitude  changes  are  effectively  instanta¬ 
neous,  i.e.,  they  are  accomplished  at  the  next  mile  marker.  To  land. 
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the  aircraft  must  be  cleared  for  landing  through  the  navigational  beacon 
(navaid)  assigned  to  the  airport.  Since  there  are  two  airports,  there  are 
two  navaids.  To  land,  the  controller  places  the  aircraft  on  a  heading  for 
a  navaid  and  issues  a  clearance  for  approach  command.  Once  the  air¬ 
craft  reaches  the  beacon,  it  automatically  assumes  the  correct  heading 
for  the  airport.  The  controller  then  issues  a  clearance  to  land  command, 
and  when  the  aircraft  reaches  the  airport  it  lands  (disappears  from  the 
screen).  If  the  controller  issues  a  hold  command,  the  aircraft  remains  at 
the  navaid  until  released. 

The  player  initially  specifies  the  length  of  the  game,  which  may  be  be¬ 
tween  16  and  99  minutes.  The  same  number  of  aircraft  will  appear  for 
each  game,  so  the  shorter  the  simulation,  the  more  challenging.  In  any 
session,  the  last  15  minutes  will  be  free  of  new  aircraft.  The  simula¬ 
tion  terminates  when  all  aircraft  have  been  successfully  dispositioned, 
the  timer  runs  out,  the  player  requests  termination,  or  one  of  three  error 
conditions  occurs; 

•  conflict  error  -  separation  rules  were  violated 

•  fuel  exhaustion 

•  boundary  error  -  the  aircraft  attempt  to  leave  the  control  space  via 
an  unauthorized  point. 

B. 1.2.2  ATC  Design  This  section  contains  a  summary  of  the  ATC  de¬ 
sign  in  general.  The  main  objects  are  discussed  briefly,  the  Ada  package  specifica¬ 
tions  for  the  main  objecs  are  listed,  and  the  Booch  diagrams  for  the  design  are  given. 
sectionGoncurrency  in  ATC 

In  the  ATC  simulation,  three  objects  contain  concurrency:  the  ATC  object, 
the  Console  object,  and  the  Aircraft  class. 


•  ATC.  The  first  and  second  heuristics  were  used  to  identify  concurrency  in  the 
ATC  object.  Examining  the  ATC  problem  description  reveals  two  separate 
patterns  of  behavior.  The  first  is  the  periodic  updating  of  the  ATC  display. 
This  is  a  task  under  the  second  heuristic,  an  object  behavior  constrained  by 
time.  The  second  pattern  of  behavior  is  the  asynchronous  processing  of  user- 
entered  commands.  The  pattern  is  a  follows:  the  user  enters  a  command. 
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the  system  responds  with  a  message,  and  the  command  is  executed.  The 
asynchronous  nature  of  this  pattern  precludes  it  being  embedded  within  the 
periodic  update  of  the  display. 

•  Console.  The  first  heuristic  identified  two  behavior  patterns  within  the  console 
object,  one  corresponding  to  input  (Keyboard),  the  other  corresponding  to 
output  (Screen).  These  objects  happen  to  model  physical  devices. 

•  Aircraft.  The  first  heuristic  was  used  to  identify  the  Aircraft  class  as  con¬ 
current.  Although  the  actual  physical  airplane  need  not  be  modeled  (flaps, 
engines,  etc.),  the  behavior  of  the  aircraft  flying  throught  the  airspace  is  an 
identifiable  behavior  pattern,  which  should  be  modeled  as  a  task. 

Two  heuristics  were  not  used.  No  computationally  intensive  objects  or  opera¬ 
tions  were  identified;  nor  were  any  concurrent  solution-space  objects  encountered. 

B. 1.2:3  ATC Design  This  section  contains  a  summary  of  the  ATC  de¬ 
sign  in  general.  The  main  objects  are  discussed  briefly,  the  Ada  package  specifications 
for  the  main  objects  are  listed,  and  the  Booch  diagrams  for  the  design  are  given. 

Main  Objects  The  main  objects  in  the  ATC  system  are  ATC,  Con¬ 
sole,  Command,  Airspace,  and  Aircraft. 

•  ATC.  The  ATC  object  is  the  primary  object  of  the  system.  It  controls  the 
interaction  of  other  objects.  As  previously  mentioned,  it  has  two  threads  of 
control,  command  processing  and  display  update. 

•  Console.  The  Console  object  handles  the  system  I/O. 

•  Command.  The  Command  class  defines  the  representation  of  a  command, 
and  provides  operations  to  create  a  command,  determine  whether  a  command 
is  a  status  request  or  a  directive,  and  identifies  which  particular  command  a 
command  variable  contains. 
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•  Airspace.  The  Airspace  object  represents  the  airspace,  which  contains  land¬ 
marks  (navigational  beacons,  airports,  and  entry/exit  fixes)  and  aircraft.  It 
tracks  the  location  of  the  aircraft,  determines  when  proximity  errors  occur,  and 
supervises  the  execution  of  commands. 

•  Aircraft.  The  Aircraft  class  represents  aircraft  as  they  pass  through  the  airspace, 
and  contains  operations  which  query  the  status  of  the  aircraft  and  change  the 
state  of  the  aircraft. 


B.l.2.4  Ada  Code 
ATC  Object 


with  C&iend^r; 

with  Tcxt!IO; 

use  Text’IO; 

with  Commixnd’PKG; 

use  Command'PKO; 

with  ConsoIe'PKG; 

with  CUsscs'PKG; 

use  Ci&ises-PKG; 

with  AirerAft'Attributes‘PKG; 

procedure  ATC  is 

Simulation'Lengths  CUsscs’PKG. SimuUtion'Time; 

This’Command:  Comm&nd’PKG. Command; 

Conlroiler'Input:  Classcs’PKG.Input'String; 

Time*Expired:exception; 

package  Time'IO  is  new  integer'io(Classes'PKG.Simulation'Time); 

task  Update'Airspace  is 

entry  Start(Siinulation'Length:  in  Classes'PKG.Simulatton'Time); 

entry  Stop; 

end  Update’Airspace; 

use  Calendar; 

task  body  Update'Airspace  is 

Time'Left:Classcs'PKG.Simulation'-Time; 

Minute’Counter:  integer:=:l; 

Time‘£xpired:exception; 

Next’Updatc:CaIendar.Tirne; 

Update'Intervahduration:=15.0; 

begin 

accept  Start(Simulation'Length;  in  Classes'PKG.Simulation'Time)  do 
Time‘Le(t:sSimulation*Length; 

end  Start; 

Consoie'PKG. Display -Timc(Time‘Lefl); 

Hcxt*Updale:=Calendar.ciock; 
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loop 

Ncxt'Upd&te:sNext‘Upd)te  +  UpdatcMnlcrvalj 
deUy  Next'Update  •  Calendar.clock; 

-  retrieve  airspace  updates 

-  display  airspace  updates 
if  Minute*Counters4  then 

Time*Left:=sTime'Left-l; 

Console'PKG.Display‘Time(Time'Left); 
if  Time’LeftaO  then 
raise  Time’Expired; 
end  if; 

Minute‘Counter:=l; 

else 

Minute'CounterrsMinute'Counter+l; 

end  if; 
select 

accept  Stop; 
exit; 
else 
null; 

end  select; 
end  loop; 

end  Update'Airspace; 
begin 

put(**Gnter  the  sjmulation  length:  ’*); 

Time*]0.get(Simulation‘Length); 

-  Draw’lnitial'Map; 

Update'Airspace.Start(Simulation‘Length): 

delay  1,0; 

loop 

ControUer'Input:sConsole'PKG.get*input; 
Console'PKG.Display'Input(Controller'lnput); 
if  Conimand'PKG.Is'Termination'Request(Controller'Input)  then 
Console'PKG.Display'Input(’*Terminating  simulation/*); 

-  Terminate’Simulation; 

Update*  Airspace. Stop; 
exit; 

end  if; 
begin 

This‘Command:=  Command*PKG.Crcate*Comrnand(Controller'Input); 
exception 

when  Invalid'Command  =i 
Console'PkG.Display’Input(”Invalld  command."); 
when  Invalid‘Aircraft  =i 
Console'PKG.Display‘lnput("Invalid  aircraft."); 
when  others 

Console'PKG.Display’Input("Something  else  v/cnt  wrong.”); 
end; 

if  not  Command*PKG.Is'Status(This'Commahd)  then 
Console'PKG.Display'Roger; 

-  Execute  Command 
else 

-  Get  Status 

•>  Display  Status 
null; 
end  if; 
delay  1.0; 
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end  loop; 
exception 

when  Time'Bxpireds^ 
put'line(*'Yo\]  r&n  out  of  time!!!!!'’); 
when  other*  =j. 

put‘line(’*Something  bad  went  wrong.”); 
cnd-ATC; 


Console  Object 


-  OBJECT:  Console 

-  REPRBSBNTATIOK:  Subobject*  •  display,  keyboard 

USED  BY:  ATC 

USES:  Display’PKG,  Kcyboard'PKG,  Classes'PKG 

-  OPERATIONS:  Display'Preview’Mcssage  •  displays  a  preview 

-  message  in  the  preview  area 

-  Display'Map'Item  •  displays  a  single  map  item 

-  in  the  map  area 

Display’Time  •  displays  the  time  rerhaining  in 
the  simulation  in  the  time  area 
Display‘Input  •  echos  the  input  to  the  screen 

-  CetUnput  -  gets  input  from  the  keyboard 

-  Dtsplay'Roger «  displays  a  "ROGER”  message  in 

-  the  response  area 

-  Clean’Up*  kills  all-tasks  at  the  terrhination 

•  of  the  simulation 

-  PURPOSE:  Provides  the  I/O  to  the  ATC  simulation. 


with  Classes'PKG; 
package  Console*PKG  is 

procedure  Display'Prcview'Message 

(Next'Message:  in  Classes'PKG.Preview’Messagc; 
Msg'Num:  in  Classes'PKG.Preview'Messagc'Count); 
procedure  Display!Map'ltcm(This‘Item:  in  Classes'PKG.Map'’Item); 
procedure  DispUy-Time(Ncw'Time:  in  Ciasses'PKG.Simutation'Time); 
procedure  Display’lnput(This'lnput:  in  String); 
function  Get'Input-rcturn  String; 
procedure  Display'Roger; 
procedure  Clean'Up; 

end  Console’PKG; 


Command  Class 


-  CLASS:  Command 

-  REPRESENTATION:  Record 

USED  BY:  ATC 
USES:  NONE 

-  OPERATIONS:  Create'Command  •  builds  a-command  from  an 
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input  Atring 

Gct'ID  -  returns  the  ID  of  the  Aircraft 
specified  in  the  passed  command. 

Is’Status  -  returns  true  if  the  passed 
command  is  a  status  request, 
false  otherwise. 

Is'Termination  •  returns  true  if  the  passed 
command  is  a  termination 
request,  false  otherwise. 

Is’icommandj,  •  returns  true  if  the  passed 
command  =  ;command^,  false 
otherwise.  There  will  be 
one  of  these  for  each 
diiTerent  command. 

EXCEPTIONS:  Invalid'Command>  this  exception  is  raised 

when  the  Direction  or 
Amount  parts  of  the  command 
are  illegal  values.  The 
exception  is-propagated  to 
the  ATC  object. 

Invalid*Aircraft«this  exception  is  raised 
when  an  invalid  Aircraft'ID 
is  detected.  The  exception 
is  propagated  to  the  ATC 
object. 


PURPOSE:  Represents  the  commands  used  in  the  ATC 
simulation. 


with  Aircraft'Attributes!PKG; 
with'Classes'PKG; 
package  Command'PKG-is 

type  Command  is  private; 

function  Create’Command  (This'String:  in  string) 

return  Command; 

function  Get'ID  (This'Command:  in  Command) 

return  Aircraft' Attributes'PKG.Aircraft'lD; 
function  Is'Status  (This'Command:  in  Command)  return  boolean; 
function  Is'Termination'Request  (This’String:  in  Classes'PKG.Input'String) 

return  boolean; 

function  Is'Clear'to'Land  (This'Command:  in  Command) 

return  boolean; 

function  Is’Turn'Lcft*45  (This'Command:  in. Command) 

return  boolean; 

Invalid'Command  :  exception; 

Invalid'Aircraft  :  exception; 

private 

-  Command  is  a  record  containing  the  following: 

-  1.  aircraft'ID  of  the  aircraft  being  commanded 

~  2.  the  direction  character  which  determines  which 
direction  the  aircraft  should  go. 

-  h  -  left 

-  R  •  right 

—  A  •  ascend/descend 

•  3.  the  amount  character  which  specifies  how  far  the 

the  aircraft  should-turn/ascend/descend 
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-  0  •  dear  to  land,  hold  at  navald,  continue 
1  -  100074s  degree* 

-  2  -  2000790  degree* 

-  3  -  3000713s  degree* 

4  .  40007100  degree* 

-  5  •  50007dear  for  approach 

-  4.  a  boolean  which  flag*  the  command  a*  a  *tatu»  request  or 

-  a  directive  command 
type  Command 

i*  record 

Aircraft'ID  :  Aircra(t'Attribute*‘PKG7Aircra(t'lD; 
Direction  :  character; 

Amount  :  character; 

Is'a'Command  :  boolean:=true; 
end  record; 

end  Command'PKG; 


Airspace  Object 

with  Aircraft'Attribute*‘PKG; 
with  Command; 
wjth  Landmark'PKG; 
with  ClassesTKG; 
packagC'Airspace’PKG  i* 


-  CLASS:  Airspace 

-  REPRESENTATION:  none- 

USED  BY:  ATC 

-  USES:  Command, .Landmark,  Clasies,  Aireiaft  Attribute* 

-  OPERATIONS:  InitializVAlrspace  •  sets  the  location  of  all 

•>  landmark*  in  the  airspace  and 

-  passe*  it  back  to  ATC  for 

-  display 

-  Update'Airspace  •  gets  the  position  updates 

-  of-the  aircraft,  ch«ck*-for 

*•  errors,  and  passe*. the  update* 

-  back  to  ATC 

-  Execute’Cornmand  -  perform*  the:*pccifled  command 

-  on  the  specified  aircraft 

-  Is'Done  •  return*  true-if-26=aircraft  have 

-  been  dispositioned 

-  Get’Landmark'Location  •  return*  the  location  of  the 

-  specified  landmark. 

-  based  on  the  heading,  speed,  etc. 

-  PURPOSE:  This  class  represents  the  airspace. 

»*«»«»«««**«)«*»*»«* H 

package  Update'Rccord'List  is  new  ???????(Update*Rccord'PKG.Update'Record); 
procedure  Initialize'Airspace.CUpdate’List:  out  Update'Record'List); 
procedure  Update'Airspace  (Update'List:  out  Update’Record'List); 
procedure  Execute'Command  (This'Command:  in  Cornmand'PKC. Command; 

This‘Aircraft;Aircraft'Attributes‘PKG.  Aircraft'ID); 
function  Is'Done  return  Boolean; 

function-Get’La}idmark’Locatioh(Thi*‘Landmark:  in  Landmaik'PKG. Landmark) 
return^Classcs'PKG.Airspace'Position; 
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end  AiMp&ee'PKG; 


Aircraft  Class 


with  Aircrafl'Position’PKG; 
with  Flight'Plan'PKG; 
with  Aircraft'Attributes'PKG; 
package  Aircraft’PKG  is 


CLASS:  Aircraft 
REPRESENTATION:  record 
USED  DY:  Airspace 

USES:  Airciaft’Attributes,  Plight'Plan,  Aircraft‘Position 
OPERATIONS;  GetTD  -  returns  the  ID  of  the  aircraft 
Get'Source  •  returns  the  source  of  the 
aircraft 

Get*Destination  •  returns  the  destination  of  the 
aircraft 

Get'ETA  •  returns  the  ETA  of  the.aircraft, 
the  time  the  aircraft  will-appear 
on  the  display. 

Get'Class  •  returns  the  class  of  aircrafti 
whether  it  is  a  jet  or  prop. 

Get'Heading  «  returns  the  heading.of  the  aircraft 
Gttt'Fuel  •  returns  the  fuel  level  of. the 
aircraft 

Get'Position  •  returns  the  3  dimensional  position 
of  the  aircraft 

Get-Aititude  -  returns  the  altitude  of  the  aircraft 

Set'ID  •  assigns  an  ID  to  the  aircraft 
Set'Flight-Plan  -  assigns  a  flight  plan  to  the 
aircraft 

Set’Class  •  assigns  a  class  to  the  aircraft 
Set'Heading  -  assigns  a  heading  to  the  aircraft 
Set'Altitude  •  assigns  an  altitude  to  the  aircraft 
Set'Fuel  •  assigns  a  fuel  level  to  the  aircraft 
Set‘Position  -  assigns  a  position  to  the  aircraft 
Take'Off  •  sets  the  Take'Off  flag  to  true 
Hold'at'Navaid*  sets  the  Hold‘at‘Navaid-flag  to  true 
Clear'for-Approach  •  sets  the  Clear’for-Approach  flag 
to  true 

Clear-forLanding  •  sets  the  Clear*for:Landing  flag 
to  true 

Continue'Straight  •  does  nothing 
Update'Position  -  sets  the  new  position  of  tne  .'ircraft 
based  on  the  heading,  speed,  etc. 


-  PURPOSE:  This  class  represents  an  aircraft  in  the  airspace 


type  Aircraft  is  private; 

function  GetTD  (This'Plan:  in  Aircraft) 

return  Aircraft'Attributes'PKG.AircraftTD; 
function  Get'Source  (This'Plan:  in  Aircraft) 

return  Aircraft'Attributes'PKG. Source; 
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function  Gct'Dcfltination  (Thls'PUn:  in  Aircr&ft) 

icturn  Aircraft' Attribute»*PKG. Destination; 
functi  1  Gcl'ETA  (This'Pian:  in  Aircraft) 

return  Aircraft'Attributes'PKG.ETA'Type; 
function  Get'Cfasi  (This'Plans  in  Aircraft) 

return  Aircraft'Attributes'PKG. Class; 
function  Get’Heading  (This'Plan:  in  Aircraft) 

return  Aircraft’ Attributes'PKG.Heading'Type; 
function  Get’Puel  (This'Plan:  in  Aircraft) 

return  Aircraft’ Attributes’PKG. Fuel; 
function  Get'Position  (This’Plan:  in  Aircraft) 

return  Aircraft’Position’PKG.Aircraft’Position; 
function  Get'Altitude  (This’Plan:  in  Aircraft) 

return  Aircraft'Attributes'PKG.AUitude'Type; 
procedure  Set’ID  (This'ID:  in  Aircraft'Attributes’PKG.Aircraft’lD; 

This'Plane:  out  Aircraft); 

procedure  Set'Flight'Plan  (This’Src:  in  Aircraft'Attributes'PKG. Source; 

This'DST:  in  Aircraft'Attributes'PKG. Destination; 
This’BTA:  in  Aircraft'Attributes'PKG, ETA’Type; 

This'Plane  :  out  Aircraft); 

procedure  Set’Class  (This’Class:  in  Aircraft'Attributes'PKG. Class; 

This’Plane :  out  Aircraft); 

procedure  Set'Heading  (This'Headinj:  in  Aircraft'Attributes’PKG. Heading'Type; 
This’Plane  :  out  Aircraft); 

procedure  Set’AUitude  (This'Altitude:  in  Aircraft’Attributes'PKG.A^'.itude'Type; 
This'Plane.:  out  Aircraft); 

procedure  Set'Fuel  (This'Fueli  in  Aircraft’Attributes'PKG. Fuel; 

This'Plane  ;  out  Aircraft); 

procedure  Set'Positlon  (Thls'-Position:  In  Aircraft'Position'PKG.Aircraft’Position; 

This'Plane:  out  Aircraft); 
procedure  Take'Off  (This'Position:  out  Aircraft); 
procedure'Hold'at'Kavaid  (This'Position:  out  Aircraft); 
procedure  Ciear'for'Approach~(This'Position:  out/Alrcraft); 
proccdure'CIear’for'Landing  (This’Position:  out  Aircraft); 
procedure  CohtInue'Straight  (This'Position:  out  Aircraft); 
procedure  Update'Position  (This’Position!  out  Aircraft); 

private 

type  Aircraft  is 
record 

ID:  Aircraft'Attributes’PKG.Aircraft'ID; 

Active:-Doolean:=faUe; 

Flight’Plan:  FHght’Plan'PKG.Flight’PIan; 

Class:  Aircraft'Attributes!PKG. Class; 

FucrLevcl:  Aircraft'Attributes'PKG. Fuel; 

Position:  Aircraft'PosItlon'PKG.Aircraft’Position; 

Approach:  Boolean:=false; 

Landing  :  Boolean:=falsc; 

Hold  :  Boolean:sfalse; 
end  record; 

end  Aircrafl'PKG; 


B.1.2.5  Booch 
higher  levels  of  the  design. 


Diagrams  Following  are  the  Booch  diagr.^,ms  for  the 
The  lower  level;  objects  and  classes  are  included  only 
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when  relevant  for  concurrency. 


ATC 


Figure  B.l.  Top  Level  Design 
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Figure  B.2.  Console  Object  Refinement 
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B.2  The  Experts 


The  following  table  lists  the  software  engineering  experts  who  participated  in 
evaluating  the  research  contained  in  this  thesis: 
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ORGANIZATION 

Karyl  Adams 

Contractor 

Capt  Paul  Hardy 

Air  Force  Institute  of  Technol.'^s:y  (AFIT) 

Dr  James  Howatt 

AFIT 

Capt  Terry  Kitchen 

AFIT 

Dr  Patricia  Lawlis 

AFIT 

Capt  James  Marr 

AFIT 

Capt  Gene  Place 

AFIT 

Dr  Bo  Sanden 

George  Mason  University 

Capt  Kelly  Spicer 

AFIT 

Dr  Marty  Stytz 

AFIT 

Capt  Jay  Tevis 

AFIT 
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6  September  1990 


FROM:  Paul  R.  Hardy,  Capt 
SUBJECT:  RE:  Evaluation  of  Design  Heuristics,  4  Sep  90,  Ltr 
TO:  Capt  Ken  Baum 

Below  arc  comments  requested  in  the  subject  letter: 

Question  1:  No  additional  comment. 

Questions  2  and  3:  The  comments  I'm  providing  stradle  Issues  raised  In 
questions  2  and  3.  First,  not  evident  in  the  write  up  for  evaluation 
was  a  mapping  from  traditional  object  oriented  analysis  and 
design  tools  (concept  map,  class  specification,  etc)  to 
identification  of  possible  casks.  This  may  be  part  of  a  more 
extensive  presentation.  This  proposed  mapping  would  be  useful  to  the 
designer  in  applying  the  heuristics.  Second,  since  it  appears  that 
the  dynamic  characteristics  of  an  object  are  the  predominant  factors 
in  deciding  concurrency  is  there  a  classification  of  objects  based 
upon  this  dynamic  behavior  which  could  facilitate  identification  of 
a  task-oriented  object?  For  instance,  an  actor  object  could  be  a 
candidate  for  a  Task.  (This  is  just  an  example.)  Have  you  found  it 
to  be  true  that  objects  which  essential  arc  similar  to  abstract  data 
types,  that  is,  have  operations  which  change  state  values  (boolean, 
numerical,  etc)  and  Inspector  operations  for  state  values,  do  not 
need  to  be  tasks?  As  opposed  to  objects  that  change  the  state  of  the 
system,  physical  or  logical,  which  map  into  task? 

Question  4:  It  is  probaby  important  to  include  "Time  Constraints"  as  a 
characteristic  of  a  candidate  cask  object.  This  attribute  can  be 
overlooked.  I  would  tend  to  believe,  chough,  chat  time  restrictions 
ate  an  attribute  of  a  physical  or  logical  entity,  for  example,  ATC 
must  update  the  airspace  every  feu  clock  cycles.  If  not  an  attribute 
of  Che  object,  most  likely,  computationally  complex  processing  is 
the  driving  determiner.  In  either  case,  time  constraints  may  be 
implicitly  embedded  within  the  ocher  heuristics.  (I  say  may  be 
because  these  are  just  comments  and  1  don't  have  to  support  any 
issues  I  raise!) 

Question  5:  No  comment. 

Questions  on  application  of  heuristics: 

In  application  of  the  heuristics  to  the  ATC,  it  appeared  chat  the 
Airspace  Object  decouples  the  Aircraft  and  ATC  objects.  Was  I 
correct  in  this  observation?  If  so,  was  there  an  explicit  design 
decision  made  to  not  follow  "'jolution-space"  heuristic?  Are 
there  heuristics  for  making  this  sign  decision? 


1  Atch 

Quescionaire 
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1.  Are  the  heuristics  understandable? 
12  3  0  5 

NO  FAIRLY  YES 


5^,  ^.y 
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2.  Do  the  heuristics  help  the  designer  in  Baking  concurrency  decisions? 
1  2  3  4  0) 

NO  SOME  YES 


3.  Are  there  concurrency  situations  not  covered  by  the  heuristics?  Which? 
GX  2  3  4  5 


NONE  SOME  .  MANY 


4.  Is  there  overlap  among  the  heuristics?  Which? 
0  2  3  4  5 

NONE  SOME  MANY 


''fW  cU-kv'J' 

'f(oL  lAliGtA 
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5.  Do  the  heuristics  violate  established  principles  of  software  engineering 
(coupling,  cohesion,  encapsulation,  information  hiding,  etc.)?  Which’ 
0  2  3  4  5 

TOE  SOME  MANY  . 

Ylvi.  (jLd 
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1  Heuristics  for  determining  concurrency. 

Following  are  five  heuristics  which  designers  may  use  in  determining  concurrency  in  object- 
oriented  designs.  The  are  based  on  the  heuristics  used  in  the  DARTSjl],  LVM/OOD(3j 
ADARTS(2],  and  Entity-life  Modcling[4]  methods. 


1.1  Problem-space  concurrency. 
eMi 

An  object  which  meacls  concurrency  in  the  problem  environment  should  be 


implemented  as  a  task. 

Concurrency  in  the  problem-domain  can  be  determined  by  identifying  behavior  patterns, 
or  sequences  of  events,  in  which  the  objects  participate.  The  objects  themselves  may  repre¬ 
sent  physical  entities  to  which  the  system  interfaces,  or  logical  entities,  such  as  an  air  traffic 
conrol  system. 


1.2  Time  constraints. 

An  object  whose  behavior  or  operations  are  constrained  by  time  requirements 
should  probably  be  a  task. 

These  may  be  periodic  constraints,  such  as  an  operation  which  must  be  performed  at  set 
intervals,  or  responsive  constraints,  such  as  responding  to  an  interrupt. 


1.3  Computational  requirements. 


ation  called  Calculate  Satellite  Coordinates.  To  do  this  in  real  time  requires  the  integration 
of  a  ninth-order  polynomial.  Depending  on  the  resources  available,  this  could  be  quite  time 
consuming  and  processor  intensive.  This  operation  should  be  a  separate  task. 


1.4  Solution-space  objects. 

An  object  introduced  in  the  software  solution  to  protect  a  shared  data  store,  de¬ 
couple  two  interacting  tasks,  or  synchronize  the  behavior  of  two  or  more  objects 
should  be  a  task. 
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,  1.  Are  the  heuristics  understandable? 

1  2  3  5 
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2.  Do  the  heuristics  help  the  designer  in  making  concurrency  decisions? 
1234 
NO  SOME  YES 


3,  Are  there  concurrency  situations  not  covered  by  the  heuristics?  Which? 
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4.  Is  there  overlap  among  the  heuristics?  Which? 
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5.  Do  the  heuristics  violate  established  principles  of  software  engineering 
(coupling,  cohesion,  encapsulation,  information  hiding,  etc.)?  Which? 
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1.  Are  the  heuristics  understandable? 
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NONE  SOME  MANY 

Cvce^c<  ,  r^vC  ylEf>=crlS 

C0W'^-P\r<ir<b  DiJtS  )T 

XN  T<ie  er<0  yve  OOfA  C/^  wWy  Y(^  HM 

irj6  i^fWv  T>Je  YO  y^gup  i;s  \0£.vr\fv  tvc  TRSy^- 

5.  Do  the  heuristics  violate  established  principles  of  software  engineering 
(coupling,  cohesion,  encapsulation,  information  hiding,  etc.)?  Which? 

rn  2  3*45 


NONE  SOME  MANY 

''  ') 

■X^O  oPiFvyV  (Mj  — U©  vevPtST*^  Iff’.vTrfY 

T}-/-i5B  9l2Jl6i^S  TYifir  SVtX'iJ)  fL5  p)H 

Ypsy--  Tve  oe^ifrfJei-'  5T,tu  lYe 

wA'^  To  0oiiW55vLf>'e  di)jeoT  •  ii^  at6- 

VhO  )Vi\/e-  ^  L/^CUiftO)(^0  To  SocCtA 

12^  1/5^1  Tlie  f^^x  TVie 

\'f<\P\JcfA6K'ATy(0  )5  STiuv..  DeS)\iv  , 
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1.  Are  the  heuristics  understandable? 

1  2  3  5 

NO  FAIRLY  YES 


2.  Do  the  heuristics  bglp  the  designer  in  naJcing  concurrency  decisions? 

1  2  4  5 

NO  SOME  YES 

(\l<a  tOOQ(>Q  Oao  C.c>un‘^^rd^C(c/n/Z .  ^ 

*■  \  ^  pW<2  Yvit^h  ^^ClLvO  Scpo-rol-e.  VdtOc  possi.'bty 

piSiA-U  \r\  Si^c<2C^Ky/<L  CorAt^  *37'’^'^20cr|  OA  c-  dcio-stru-thd^e- 

(>£,^VuvAi^^o.  ,r.fk  fer  O.VV  i^yr  ^vcmCS ci^cSDijfeJ.  ?) 

lOaolO-  O'TnVv/  One.  4<<>lt-  a^^d  iCOold  tverefcrc  calCiO  n'OTC,  Qpi'-  '•imi  H  Vie.  dfu’Ctcd, 

\c>  rood  there  concurrency  situations  not  covered  by  the  heuristics?  Which? 

0  2  3  4  5 

NONE  SOME  MANY 


4.  Is  there  overlap  aaiang  the  heuristics?  Which? 

1  2  (3^  4  5 

NONE  SOME  MANY 

~S>x!to>-  Oa>'  Ql'yC'CSL  of- 

V\QUr\S,V,'cS,  o.%  cAxmQ.. 


5.  Do  the  heuristics  violate  established  principles  of  softuare  engineering 
^coupling,  cohesion,  encapsulation, 

Q)  2  3  4 

NONE  SOME 


information  hiding,  etc.)?  Which? 
5 

MANY 
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1.  Are  the  heuristics^^derstandable? 

1  2  [3)4  5 

NO  YES 


2.  Do  the  heuristics  help  the  d' 


;ner  in  making  concurrency  decisions? 
5 

YES 


3.  Are  there/Cbucurrency  situations  not  covered  by  the  heuristics?  Which? 
1  [  2  )  3  4  5 

NONE  SOME  MANY 


4.  Is  there /^erlap  among  the  heuristics?  Which? 
1  (2)3  4  5 

NONE  Vy  SOME  MANY 


o  tne  heuristics  violate  established  principles  or  sottware  engiLeen 
^upling,  cohesion,  encapsulation,  information  hiding,  etc.)?  kiich? 

^2  3*45’ 

NE  SOME  MANY 
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Commty^ih  SEP.  1  9 '98® 

1x1  Doty)  i'v'-^-XtJ.  Coy\Cuyfyty\C'‘^  ?  7Vvi5  C-oiy/oi 

j>ir-k<K,^{  he.  rtj>hro.Ce^l  ^ 

o(rje<Jr  r^rey}uJ^  «  'V 

Con  dU,rrtt-0!!‘  \rx'hhx  H-xyne.  ^Uuyy'  O^'e^eJ^ 

/s  /r-^^'c.  O<ov\lr%^  S^/Ajv,  '  a  eJcat^Ci 

V}o^cL-yx'\c  ^(Xlraro^ ''  <a  L-eMor-  or\e.? 

1x2.  Tk^s  IS  /Urc/  ^  UyiaLri/^^  ^  ^ri-/. 

1}'^  M<  2.  ;  isJrj  (ycsf-  //sAje^ 

■\ahj(y9  ^yuA^  o\c/)'(^  civxA  ij  'U-^  (StCje^i/  kk^ct 

^  ov\Xo  Ic  )w-/drTU^^ 

/i2  TTn'i  A?  I-'y^-tA  i j.  ‘MjL  CCi'y^iAji'a.h  Cjf\y 

■hn.  tA>Vv\€..^  OviJ^  c(jtyy\jkh^  Q\AJol4\^yr- 

&4~je^  I's  ua.>  Awy  y/or  AAuiiy  ^ 

cUj^i/rUyJ-  huAyn  'W/CVt  'f  . 

/.'Y  T/uv^  Ifuie  AoLii  Ud.  h(ci.jySayr<Ux 


^lirxUr  finV^'^i^WiCtyxii  e\^ly{yy 
(^7-  h^/ln  Apo  ? 


C4CA1  Mu^cU  OyJ. 

[h^ei^du  F'9  iVJt-  AdAyx.  /tx^  ACj.^ 
/(\4.  AccA  ^  hyO\.J 

Cf^yLLd  So^f^C^yrt.  ^^V)ydyucJ^f.)^ 

Ciu-  0-4^  co^  ij 

<v 

i'-i  Co  »rn  * 


SfK’tr 


1.  Are  the 

heuristics  understandable? 

1 

2 

3  4  ) 

5 

NO 

FAIRLY 

YES 

t- 

^  .-r 

Ay 

t'Op^p'pif  yc-* 

fey 

2. 


Do  the  heuristics 
1  2 
NO 


help  the  designer  in  making  concurrency  decisions? 
3  4  0 

SOME  YES 


3.  Are  there  concurrency  situations  not  covered  by  the  heuristics?  Which? 
1  3  4  5 

NONE  SOME  MANY  >,  ^ 

-tojks,  7k;j  ./s  f'oUiJ,  rau*r^  o^c/ct 

fi.ff  hay.-t-e  bv1  O'O/f^t  if  cA-af, 

^  P  dieJf  *'0  if^ftn.fts,  li/l„-cii  a»e  if  foi  i-'e.’tir-y  i 

I  s  s  4\  Is  there  oveiTap  among  the  heuristics?  Which? 

1  (J)  3  ^4  5 

NONE  SOME  MANY 

/\S  <^^ov6. 


5.  Do  the  heuristics  violate  established  principles  of  software  engineering 
(coupring,  cohesion,  encapsulation,  information  hiding,  etc.)?  Which? 
(0  2  3  4  5 

NONE  SOME  MANY 

-  -'-ik  roAisfj  aUt  ^  y°' 

^  fd^  Co/culo  pye/ft  "fo', 

1.  fP'f  To  7/iz 

lA  Tfip  COJ*  p-f  'Jy. ^  frorp/tot, 

4  Alices  CCt^fUloA  to  iff  ■  Cr/4  to  O.Ap-tl^fr  /- 
c4  faskr  ^<pr  ’"o 

A/  <M'-fitoCfSPot  Jo^-fn-py 


hs 

yo'p 

^.th 

fo 

f/o 

Oap 

fiitr 

y  pocfs- 

To  f  *  > 
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1  Heuristics  for  determining  concurrency. 

Following  nre  five  heuristics  which  designers  may  use  in  determining  concurrency  in  object- 
oriented  designs.  The  are  based  on  the  heuristics  used  in  the  D.-\RTS(l).  L\'.\l/OOD(3) 
.■\D.-\RTSj'2i.  and  Entity-life  Modeling(-{|  methods. 


^  1. 


1  Problem-space  concurrency. 

\  object  which  models  concurrency  in  the  problem  environment  should  be 
mipleniented  as  a'\ask. 

Concurrency  in  the  proOiem-domain  can  be  determined  by  identifying  behavior  patterns, 
or  sequences  of  events,  in  which  the  objects  participate.  The  objects  themselves  may  repre¬ 
sent  physical  entities  to  which  the  system  interfaces,  or  logical  entities,  such  as  an  air  traffic 
conrol  svstem. 


\ 


1.2  Time  constraints. 

An  object  whose  behavior  or  operations  are  constrained  by  time  requirements 
should  probably  be  a  task. 

These  may  be  periodic  constraints,  such  as  an  operation  which  must  be  performed  at  set 
intervals,  or  responsive  constraints,  such  as  responding  to  an  interrupt. 


1.3  Computational  requirements. 

An  object  whose  behavior  or  operations  require  substantial  computational  re¬ 
sources  should  probably  be  a  task. 

For  e.Nample,  in  a  satellite  communication  system,  the  satellite  object  may  have  an  oper¬ 
ation  called  Calculate  Satellite  Coordinates.  To  do  this  in  real  time  requires  the  integration 
of  a. ninth-order  polynomial.  Depending  on  the  resources  available,  this  could  be  quite  time 
consuming  and  processor  intensive.  This  operation  should  be  a  separate  task. 


1.4  Solution-space  objects. 

An  object  introduced  in  the  software  solution  to  protect  a  shared  data  store,  de- 


couple  two  interacting  tasks,  or  synchronize  the  behavior  of  two  or 

more  objects 

should  be  a  task.  ^  1  ■> 

,  .  ■?  or  ^  1  ' 

\  'fi  ' 

r  i 

I'Y  0 

'  1 

r  1  • 

t-'O 

11  j:-'"" 

.  ,  .  </(l  • 

ff 
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1.  Are  the  heuristics  understandable? 

1  2  (3)  4  5 

NO  FAIRLY  YES 


/  -Oi/ 


2.  Do  the  heuristics  help  the  designer  in  making  concurrency  decisions? 
1  2  3  4  (s) 

NO  SOME  YES 


3.  Aje  there  concurrency  situations  not  covered  by  the  heuristics?  Which? 
(y  2  3  4  5 


NONE 


SOME 


MANY 


/yu/hC/  ' 


4.  Is  there  overlap  eunong  the  heuristics?  Which? 
(9  2  3  4  5 

NONE  SOME  MANY 


5.  Do  the  heuristics  violate  established  principles  of  software  engineering 
(coupling,  cohesion,  encapsulation,  information  hiding,  etc.)?  Which? 


1.  Are  the  heuristics  understandable? 

1  2  3  (4)  5 

NO  FAIRLY  YES 

—  'X'h/f'h 


2.  Do  the  heuristics  help  the  designer  in  making  concurrency  decisions? 

1  2  3  4 

NO  SOME  YES  . 

-  ii,  (e>u~t  nY>nrt}'h'<r 

y/>i/'r-  /p.'r^t  <Pt^  r/^  ^ 


3.  Are  there  concurrency  situations  not  covered  by  the  heuristics?  Which? 

2  3  4  5 

NONE  SOME  MANY 

{juf  S  '^hfik  p~F  <yr'<s» 

I'J  -ft)  ^  ^ 

4.  I>,  there  overlap  among  the  heuristics?  Which? 


5.  Do  the  heuristics  violate  established  principles  of  software  engineering 
^oupling,  cohesion,  encapsulation,  information  hiding,  etc.)?  Which? 
(1,  2  3  4  5 

NONE  SOME  MANY 
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1  Hoi-iistics  for  determining  concurrency. 


Following  are  five  heuristics  which  designers  may  use  in  determining  concurrency  in  object- 
oriented  designs.  The' are  based  on  the  heuristics  used  in  the  DARTSjl),  LVM/OOD[3] 
ADARTS(2],  and  Entity-life  Modeling(4)  methods.  .7  ' '  }-^ 

_ _ _ 

1.1  Problem^spac^concurrency. 

An  object  which  models  concurrency  in  the  probleni[environment.ihould  be 

implemented  as  a  task.  — - 

Concurrency  in  the  problem- joinaiiTcan  be  determined  by  identifying  behavior  patterns, 
or  sequences  of  events,  in  which  the  objects  participate.  The  objects  themselves  may  repre- 
jfiaL4dj\'sica!  entities  to  which  the  system  interfaces,  or  logical  entities,  such  as  an  air  traffic 
''«qnrol,iystem. 


r 


[”1.2  Time  constraints. 

I  An  object  whose  behavior  or  operations  are  constrained  by  time  requirements 
\  should  probably  be  a  task. 

These  may  be  periodic  constraints,  such  as  an  operation  which  must  be  performed  at  set 
intervals,  or  responsive  constraints,  such  as  responding  to  an  interrupt. 


rr 


1.3 


Computational  requirements. 


.V 


An  object  whose  behavior  or  operations  require  substantial  computational  re¬ 
sources  should  probably  be  a  task. 

For  e.xample,  in  a  satellite  communication  system,  the  satellite  object  may  have  an  oper¬ 
ation  called  Calculate  Satellite  Coordinates.  To  do  this  in  real  time  requires  the  integration 
of  a  ninth-order  polynomial.  Depending  on  the  resources  available,  this  could  be  quite  time 
I  consuming  and  processor  intensive.  This  operation  should  be  a  separate  task. 

yhi'  ^ 

1.4  Solution-space  objects.^T^  -^'rar-  ln-inl  I'n 


^  An  object  introduced  in  the  software  solution  to  protect  a  shared  data  store,  de- 

-  ^  couple  two  interacting  tasks,  or  synchronize  the  behavior  of  two  or  more  objects 
should  be  a  task. 
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